[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.


Other related posts: