Onward branch

Jan Dvorak jan.dvorak at sitronicsts.com
Wed Sep 17 00:20:16 PDT 2008


On Wednesday 17 September 2008 04:20:56 Robert Connolly wrote:
> On Monday September 15 2008 03:17:04 am Jan Dvorak wrote:
> > > The more_control_and_pkg_man.txt hint system is tedious, but it
> > > identifies every problem with filesystem permissions and packages,
> > > for us. It's a big helper.
> >
> > Nope, it's totall overkill. You never ever run a program under a
> > package user. The only reason for them is to install files safely,
> > which can be done without polluting your passwd and group files and
> > making all *nix people around scream with horror after looking at `ls
> > -l` output.
>
> An alternative would be two users, an owner (user-1) of most of the
> filesystem (/usr, /lib, /bin), and a build user (user-2). The two users
> are in the same group. user-2 has write permission on /usr, and can
> install there, but can't overwrite user-1's files. After an install,
> the new files have their ownership changed from user-2 to user-1, and
> group-write removed. This keeps packages from overwriting eachother, an
> installed-files list can be made for each package before (or during)
> ownership change, and it only involves two users.

This sounds like package users simplified enough to be usable. If you want 
to maintain which package installed the particular file, you can always 
enable user_xattr and use extended attributes instead.

But still, the de-facto standard out there is to install as unprivileged 
user elsewhere, create package and then merge it into the system. Glibc, 
gcc, binutils, probably all other GNU packages in the book can be 
installed like this without any modifications.

Other acceptable approach would be the installing packages to separate 
directories. It would require a bit of scripting, but in the end, you 
would install to a dedicated g+w,o+t directory and use a script to chown 
package, symlink selected files to /usr and run some specialized thingies 
like install-info...



More information about the hlfs-dev mailing list