[haiku-development] Re: Question about /system and /boot/system
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 02 Mar 2011 21:39:23 +0100
On 2011-03-02 at 18:54:16 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 2011-03-02 at 18:12:32 [+0100], Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
> wrote:
[ ... ]
> > Yes again, keeping the current folder structure in /boot/home/config for
> > unpackaged software is probably the most elegant solution available.
> >
> > I like the whole morphing idea so much that I wonder if there isn't a way
> > to
> > get it working for multiple concurrent users, too?
>
> I'm a bit confused. Actually that was my very vision (though not fully
> implemented) when I wrote the initial packagefs. The idea was to associate
> each user's package domain (IIRC you renamed the term) with the respective
> user's ID and only make it visible to processes with that UID. I thought you
> explicitly decided against that approach.
Oops :-)
I apparently failed to read your original vision from the code - now there's
an argument for comments and/or documentation ...
> And you actually convinced me that
> mounting three separate packagefs instances (or rather 2 + n) would be
> preferrable anyway.
But all I did was to argue against a unionfs putting a writable layer on top
of a packagefs-mount. That kind of setup is hard to manage, as the user can
put files on top of the packagefs, which can cause all kinds of problems at a
later stage.
> * The main reason I found the original idea so interesting was that a
> package
> would believe that it was installed in the same location regardless of
> whether it was installed system-wide (i.e. in "common") or only for one
> user.
> This would avoid trouble with ported software packages that hard-coded
> absolute paths.
And that still would be a cool feature to have.
> Though, as you argumented, there are Linux distributions (or
> rather package management solution) that have apparently already solved that
> issue as they allow per-user installations.
/me searches for his pills ...
Did I? Off the top of my head, I can't remember any package management
solution that does that. And I guess there isn't really a lot one can do to
circumvent an absolute path embedded in a program, at least not without
applying some kernel/filesystem magic.
> * Obviously the showing/hiding of packages on a per-UID basis is
> significantly more complex to implement (unlike the alternative, which is
> already usable). We might also run into problems with it, like singleton
> server processes running as root (or some dedicated user) not seeing
> per-user
> files (e.g. app-server and user-locally installed fonts). Or seteuid()
> programs being confused by a changing environment.
Yeah, we'd probably have to pass around the user credential between processes
a lot. Although I wish we could do it, I doubt that this is ever going to
work well.
Bummer.
So we either ignore multi-user for now or we are back to using one of the two
shine-through proposals.
Only to make this clear: using separate mount points for common and user
packages would mean that only software that can be built without any absolute
paths could be activated as user package!
For many ports (e.g. automake, git & subversion), this is not the case and
they will require some hacking to remove those absolute paths.
cheers,
Oliver
Other related posts:
