Onward branch

Robert Connolly robert at linuxfromscratch.org
Fri Sep 19 19:28:51 PDT 2008


On Friday September 19 2008 01:45:46 am Mordae wrote:
> On Friday 19 September 2008 01:42:43 Robert Connolly wrote:
> > On Wednesday September 17 2008 03:20:16 am Jan Dvorak wrote:
> > > 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.
> >
> > I still like the idea of databasing filenames of packages into files,
> > because this is the fastest way to retrieve it. Using extended attributes
> > might have other advantages though.
>
> Of course it is. It's the same problem as with original package users.
> Searching large the directory trees is slow.

It took me 1 minute 36 seconds to run find(1) through /usr, with 532,385 
files. The vast majority of these files are in /usr/src. 13 minutes 58 
seconds to run find on /, with 2,500,932 files.

If you like to leave your sources unpacked in /usr/src, or have some other 
huge tree somewhere, then it can take a while to search for newly installed 
files. If you have a directory with millions of files, this directory could 
be excluded from the find(1) command, assuming the build user doesn't have 
write permission on it. Some directories, like /home and /tmp, would also be 
excluded.

This isn't a big problem when installing the core system, but it becomes a 
problem when installing packages later.

It just occurred to me to install blfs packages in /usr/local, or /opt, so 
these searches would be faster, but this is a workaround and is very 
inconvenient since the blfs book uses /usr.

Installing to a temporary directory and copying files to the system is also 
inconvenient, for the same reason. Some packages will need some work to get 
them to cooperate. If one in twenty packages need Makefile's edited to get 
them to install to $tmpdir/$pkg, is this faster or slower then running 
find(1) on / for every install? At least the find(1) command is automated, so 
I think this is preferable.

> > > 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.
> >
> > This would still use two unprivileged users... one to build and install
> > to elsewhere, and the other to own the packages on the real system.
>
> Right. Ideally "bin" with id 1 and then some other for builds.

I don't know if there are any standards for this. It's not important, only 
vanity, but it should be something reasonable.

> > > 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...
> >
> > I don't think this is worth the trouble.
>
> Actually, it's not as bad as it looks like, but it's not the "standard" way
> to do things.

I don't see how this would work with something like glibc. Some of glibc is 
installed to /lib, and some in installed to /usr/lib, so where would the 
glibc-real_files/ go? We need to be able to boot without /usr mounted.

> So, are we getting somewhere? What will the future build system be like?

It's coming along. I'm trying not to cross the line into package management, 
while also being compatible with it.

I'm asking myself how a distribution package maintainer would create packages 
for one hundred different packages which follow no standards, and how to do 
it as efficiently as possible. The more_control_and_pkg_man.txt hint accounts 
for this.

Who would have guessed it is so complicated to disallow packages from 
overwriting eachother's files.

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20080919/705a5248/attachment.sig>


More information about the hlfs-dev mailing list