[haiku-development] Re: RFC: Package management and handling of settings files
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 23 Apr 2013 21:04:26 +0200
Hi,
Am 23.04.2013 um 18:04 schrieb pulkomandy@xxxxxxxxxxxxx:
> On 2013-04-23 at 17:01:40 [+0200], Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
>> 2. Potentially incompatible settings
>>
>> Not unheard of in ported software. Some kind of configuration file is
>> required and the format respectively the default configuration changes.
>> The package format could allow marking the file as "mergeable" for
>> simple text formats, in which case an attempt could be made to merge
>> changes made by the user with those introduced by the newer version.
>
> I'd not even try to support this at the package manager side.
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.
> This is a
> problem it can't solve. There are, on the other hand, valid solutions for
> most software :
>
> - Modifying software to understand older versions of the settings file.
> Problem solved.
> - Using a multi-file configuration. The default settings go in a read-only
> directory, and the user can create a custom setting file in the user
> settings dir, with only the settings he wants to override. This way, there
> is nothing to merge, new options are added to the read-only file with
> default values, and user customizations are kept.
I am not seeing how any of this applies to the original question. Agreed, the
software should handle it. But the question is what to do with the software
that doesn't. Fixing all software before it can be included in Haiku's package
management doesn't seem to be a practical option. ;-)
Best regards,
-Stephan
Other related posts:
