Managing required packages in nALFS

Vassili Dzuba vassilidzuba at
Fri Sep 6 13:10:24 PDT 2002

On Fri, 6 Sep 2002 08:17:39 +0000 (UTC)
jamie_bennett at (Jamie Bennett) wrote:

> > -----Original Message-----
> > From: Vassili Dzuba [mailto:vassilidzuba at]
> > Sent: 05 September 2002 21:08
> > To: alfs-discuss at
> > Subject: Managing required packages in nALFS
> > 
> > 
> > Hello all ALFS'ers,
> > 
> [SNIP]
> > More details and the patch are available at 
> >
> > as well as an updated version of the documentation of the DTD.
> >
> >Any comment ?
> >
> >Vassili Dzuba
> Hi, Vassili,
>   I like what you are doing with nALFS. I've started using your
> patches (especially the reference patch) in my work already
> and as far as I can see its a useful addition.
>   As for this patch, I took a quick look at it last night
> and its a good idea. Producing stamp files on successful
> builds is a different way of doing what I was trying to 
> do (I was looking at the package's log for a success entry).
>   I suppose the natural progression is that when a package
> fails because it doesn't have the necessary dependency, nALFS
> will search a pre-defined profile directory and if the profile 
> is there it will either look for the package in the package dir
> or download it using your reference tag.

My idea (but i don't know if i'll have the time/energy to implement it
is to) was :

- add a ID attribute to the packages, that should normally be the
  name of the package
- when a package is not found, use the name of the package as an IDREF
  to find the XML element having such an ID attribute
- build the element found and, if successfull, go back to the
  first package.

This has the advantage of not having to modify the XML tree (which is assumed
to contain all the necessary packages), and to be able to display the build status
in the tree of both packages. 

I guess that by using XInclude, taht is supported by libxml2 according to the doc,
we can build a complete tree frem separate XML documents (each having its 
prolog with its own entity declarations), so that the profile directory
you mention could be loaded onece when starting nALFS.

Of course, it will be necessary to be able to suspend a processing, start another
one and come back to the first. I don't know nALFS well enough at this time to know if 
it would be easy to do so.

>   I don't know how easy/hard it would be to dynamically load in
> another profile, stop executing the one your at, execute the
> new one and then resume where your were before. I would think 
> that this would be a more involved patch but well worth it.
>   On a side note I had the following problems with your LFS-CVS 
> profile.
> 	o	I had to change chapter5/unprivileged_user from
> 		<ownership user="&lfs-user;">
> 			<option>recursive</option>
> 			<name>&LFS;/static</name>
> 		</ownership>
> 		to 
> 		<ownership user="&lfs-user;">
> 			<option>recursive</option>
> 			<name>&LFS</name>
> 		</ownership>
> 		as I was getting access denied messages for lfs-user.
> 		I presume this is because lfs-user doesn't have
> 		permission to write to &BUILD_DIR (/usr/src)?

Well, I didn't change this file from the original one, but I had a problem
in the file mounting_packages.xml, when the user lfs had no the rights
to create the package directory. It is why i added

    <permissions mode="777">

to chapter4.xml.

But in my case &build-dir; is /usr/src and &packages_dir;
is /usr/src/packages-&LFS-version;, so that &packages-dir is in fact
a subdirectory of &build-dir;, while in fact the Book suggests
to make &package-dir; a subdirectory os &LFS;static.

So, instead of changing the permissions on /usr/src, we can use something like :

<!ENTITY packages_dir "/static/packages-&LFS-version;">
<!ENTITY build_dir "/static/build">

the build in the chapter 5 seems to run OK (i interrupted it because it
takes a loooong time on my machine).

> 	o	glibc bombed out in chapter 6 with the following
> 		message from configure: -
> 		-: checking for mig
> 		-: configure warning:
> 		-: *** These auxiliary programs are missing or too old:
> msgfmt
> 		-: *** some features will be disabled.
> 		-: *** Check the INSTALL file for required version.
> 		-: checking whether ranlib is necessary ... no
> 		-: checking LD_LILBRARY_PATH variable ... contains current
> directory
> 		-: configure: error:
>             -: *** LD_LIBRARY_PATH shouldn't contain the current directory
> when
>             -: *** building glibc. Please change the environment variable
>             -: *** and run configure again.
>             I haven't a clue what this variable should contain so I didn't 
>             know what to do. Sorry.
>   Thanks

LD_LIBRARY_PATH contains the list of the directories where one can find
dynamic libraries. It is not used with LFS, where one put that list in 
/etc/, but i guess your host system uses it.

I suppose that the message signifies that that list of directories
contains the current directory, which probably would maek the build process
fail when the gclib library is created.
You should simply remove the '.' in the value of that environment variable.

> -- --------------------------------------
> - Jamie Bennett     - 18 St Peters Terrace - jamie at -
> - Software Engineer - Lower Bristol Road   -                   -
> - PCP Microproducts - Bath, England        -                   -
> ----------------------------------------------------------------
> -- 
> Unsubscribe: send email to listar at
> and put 'unsubscribe alfs-discuss' in the subject header of the message

Vassili Dzuba
Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list