[haiku-development] Re: RFC: Package management and handling of settings files
- From: pulkomandy@xxxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 24 Apr 2013 17:49:58 +0200
> I don't find that nice. I frequently find myself in the situation where I
> desperately want some help from the package management in getting rid of
> bogged configurations. I.e. I don't want package management to ignore the
> problem of settings. Ingo's proposal is to at least "mark" packages where
> merging should be possible. Sounds good to me. But even if merging is not
> possible, I want PM to be aware of settings. For example, it should at
> least allow me to get rid of any customizations (overridden default
> settings) when deinstalling a package.
Well, it's certainly fine for the package manager to know that a new version
of the file is available, and the older one might be incompatible.
Taking Debian/apt as an example (maybe other package managers do better ?),
it will try to do a 3-way merge (knowing the previous version of the settings
files, the user modified one, and the new one). The problem is :
- The merge often fails. Examples are when an option is removed/renamed and
was modified, or the file was just reorganized, etc.
- Even if the merge succeeds, you're not sure that the merged file will work
with the new version of the package. This leaves you with an even worse
situation: you're left with only the merged config file, and no trace of any
of the original versions. (Debian now keeps the 3 versions next to the file.
That solves the problem but clutters the settings directory with a lot of
older version of setting files over time).
The merge process is also painful to integrate in the package management
system. In command-line, Debian will ask what to do each time it encounters
such a file, which means you have to wait for the questions as packages are
installing. In an UI-based package manager/update application, it's not easy
to ask the user what to do in a simple way (we can list the places where the
process failed, but that leaves the user clueless with how to solve the
problem anyway).
I think this moves the bad experience of "ported software stops working after
an upgrade" to "Haiku package manager corrupts configuration files and leaves
programs in non-working state".
I don't think we can do more than warning the user about a conflict of
settings files.
For software that really can't handle more than a single settings file, I'd
go with a default one in the package (read-only) and let the user copy it to
its home directory and modify it if needed. Since we already patch most of
the software to use find_directory anyway, I don't see how that would make
the porting task significantly more work.
As long as the software can handle a way to include a configuration file from
another, the user settings can do so and just set the few options the user
wants to change. This makes the settings file easier to understand. I think
most ported software will allow that.
If the format of the file changes completely from a version to another, that
solution won't work. But any guesswork the package manager could do to try
merging the files is unlikely to do better.
--
Adrien.
Other related posts:
