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