[haiku-development] Re: Question about /system and /boot/system

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 03 Mar 2011 17:24:50 +0100

On 2011-03-02 at 21:39:23 [+0100], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> 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 ...

Oh, did I forget to write those? ;-)

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

We'll talk about the pill-popping later in today's session. ;-)

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

AFAIK Zero Install allows per-user installation of software and IIRC you 
mentioned another one that does, too. And, of course, the argument was not 
that they magically deal with absolute paths, but rather that obviously the 
packages have been built for them in such a way that they don't use absolute 
paths after all. So it should be possible for us to do the same. Well, or 
there's some serious magic going on after all...

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

Ignoring multi-user is not really an option IMO. We'd just have to scrap the 
approach later.

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

If that's the case and we decide not to hack the packages, the options are 
either to build two versions of the concerned packages, or live with the 
restriction that they can only be installed in /boot/common, or we provide 
some FS magic after all. The latter doesn't have to happen in the packagefs 
itself. A packagefs related FS could provide symlinks e.g. under 
/boot/packages, each being named like the package (or rather resolvable) and 
pointing to its activation directory (e.g. "git-1.7" -> "/boot/common", 
"subversion-1.7" -> "/boot/users/walter/config", etc.), taking the UID of the 
calling process into account. This way packages that hard-code absolute paths 
could be built to use the /boot/packages/<resolvable containing the file>/... 
paths, which are independent of where the packages are installed. Sane 
packages would continue to rely on the PATH, LIBRARY_PATH and friends and 
servers would still search the usual directories (user home, common, system), 
so there shouldn't be any nasty side effects.

Another alternative would be an assignfs as suggested a while ago by Brecht 
(IIRC). At least it would work for directories for which an assign has been 
defined ("bin", "lib", and a few others) and only if the target file is 
directly in that directory or package-unique subdirectory (otherwise full 
unionfs support would be required).

CU, Ingo

Other related posts: