[haiku-development] Re: Some thoughts on package management
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 17 Oct 2013 17:50:11 +0200
On 10/17/2013 11:25 AM, Adrien Destugues wrote:
So, while most users can get away with having /boot/system read-only
(that's a good thing despite the incompatibilities it has with some
software and/or installers), most of them don't agree with having
home/config read-only. I agree on that, and think we should leave the user
manage its home directory the way he needs it.
There's home/config/non-packaged for exactly that purpose.
Having a package-managed home/config is useless. The purpose was to mount
home-grown packages there, but since this isn't looked up by the
development tools, it's not handy to drop a library or devel package there
and have it working immediately.
As written before, that is just a question of adding the paths in
question to the respective environment variables.
Only 'final' packages (binaries and apps)
can be used there, and even that requires some extra support so the
packages look for everything in their .self directory.
No, not everything; just global per installation location resources.
It also makes it
unpractical to have an app in /system and add-ons for it in /home/config
Package management has changed nothing in this respect. If an
application searches all add-ons directories it did and still does find
add-ons in home/config.
On the other hand, we really need a way to tell apart 'managed' packages
(installed from pkgman) from 'non-managed' ones. This information can be
retrieved from pkgman, but tagging the packages somehow (say an FS
attribute) with the source URL/repo would be nice. This would make it
possible to query for 'all packages installed from haikuports' or 'all
packages installed manually'.
There is no difference between packages installed via pkgman and those
installed manually. You can download a package from the haikuports
repository and install it manually, and -- the feature has not been
implemented yet -- pkgman will also be able to install a local package
file. It is not relevant by which method a package is installed. The
relevant information is encoded in the package meta data: the package
vendor.
Finally, I'd suggest mounting all packages in /system, no matter if they
come from /system/packages or /home/config/packages. In a multiuser system
this would mean each user sees a different /system directory, but it allows
installing custom packages for each user in a transparent way.
IIRC that's actually how I thought things would work when I originally
wrote packagefs (feature removed in
6978941aac85ea329a8552253f384924dcccd1b3). Particularly when we go
multi-user, this adds significant complexity to the implementation,
makes it much harder to understand things (e.g. that system programs
won't pick up entries provided by packages in a user's home), and
probably wouldn't allow installing multiple incompatible versions of a
package.
This allows
the user to keep untested packages in /boot/home, and possibly boot in safe
mode without enabling those if something goes wrong.
How is that different from now?
Yet, it keeps the FS
hierarchy simpler, with a single package-FS managed directory in the system.
Unfortunately bought with additional complexity and obscurity.
CU, Ingo
Other related posts:
