[haiku-development] Re: RFC: Package management and handling of settings files
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 25 Apr 2013 12:37:16 +0200
On 04/24/2013 05:49 PM, pulkomandy@xxxxxxxxxxxxx wrote:
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).
Haiku would keep all necessary versions of the file in either case,
though probably not in the settings directory, but in a dedicated
subdirectory in packages/administrative/.
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 would simply present a list of all concerned files with their
respective status (the status texts may be more user-friendly):
* "not merged": Merge necessary, but disabled by the user.
* "merged": Merge successful.
* "merge failed": Merge necessary, but failed.
Selecting an entry (or double-clicking it to bring out a new window)
would show additional info. If we wanted to go all out, we could even
implement a dialog to assist with the merge.
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".
As written before, that's why the user should always be notified of the
situation. I.e. after an update the problems and potential problems
should be clearly listed. Ideally it would also be possible to inspect
the status of a recent update at a later point.
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.
User-specific settings aren't really the files we're talking about. I
don't think there's that many ported software that requires a user
specific settings file. In most cases those will be optional, explicitly
created by the user, and likely reasonably forward compatible anyway. Or
the software notifies the user when started that a configuration file is
required or the existing one is obsolete. That's simply what multi-user
systems dictate, since you can't mess with all users' settings when
updating a software, and when creating a new user, creating settings
files for all installed software isn't sensible either.
The interesting cases are the global configuration files (stuff that
normally lives in common/settings). In some cases you'll probably never
want to edit them or maybe just add/change a line or two (e.g. your
"man" configuration) while others may be highly customized (e.g. your
apache config). The package manager's merge feature would mainly be
helpful for the first group.
On 04/24/2013 06:09 PM, Antti Soininen wrote:
[...]
> If user has not modified a configuration file and a new is available,
> the old one is always overwritten.
Yes, I think that's a given. Both alternatives -- leaving the old file
or bothering the user -- would be highly annoying.
On 04/25/2013 12:01 AM, Clemens wrote:> On Wed, 24 Apr 2013 03:01:40
+1200, Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> is this case included?
>
> 4) Not installed packages
>
> For example, an app on a removable drive for portable usage that is
> opened by just double clicking the hpkg file.
>
> Should the app know if its installed or not?
> Should the app know what hpkg it lifes in? e.g. to attach settings to
> its package file
>
> In this way an app opened by double clicking a hpkg file would know
> that it should not write settings into the home directory but attach
> it directly to the package. Copying the package to the install
> directory of a new host would omit this settings and install fresh
> settings to the settings directory of the new environment.
>
> However, settings directly attached to a hpkg might be dangerous
> because the settings may also contain passwords. A user who only
> wants to copy the app may not realize that --> a settings dir on the
> removable drive?
We haven't given the "app bundle" concept much thought yet. One idea is
to simply temporarily activate the package in home/config (i.e. an
application would usually appear in home/config/apps/) or in a packagefs
volume for that purpose alone. An API could be added to allow the
application to determine whether it has been activated just temporarily.
Storing settings in the package file's attribute is not a good solution
IMO. Such an attribute would not normally be visible to the user and
therefore easily unknowingly copied. Which is indeed a problem for
sensitive data. Even for harmless ones I wouldn't find it nice, if
another user inherited settings simply be copying the package.
A better alternative might be to require the user to explicitly set up
an installation location on the removable media -- basically just a
directory with a "packages" and a "settings" directory and maybe some
marker. A new packagefs volume would then be mounted there and the
application would store settings there as well. If the package doesn't
live in such an installation location the application would use the
user's settings directory as usual. This would still need explicit
support from the application, I think.
Anyway, since the application bundle feature isn't high priority, we
probably won't implement it before merging the package management branch
back to the trunk. The same goes for any more advanced settings file
handling BTW. Initially, installing new and auto-updating unchanged
settings files is a reasonable feature set to go for.
CU, Ingo
Other related posts:
