Package Management Options manuel at
Tue Oct 17 12:20:40 PDT 2006

El Martes, 17 de Octubre de 2006 20:00, Dan Nicholson escribió:
> I've been thinking about how the paco patch is currently managed and
> was trying to think how package management could be more general in
> jhalfs. Unfortunately, my understanding of xsl sucks. Maybe you could
> point me in the right direction on my thoughts.
> What I was thinking was that commands that install to the root
> filesystem in LFS always be defined with a role, such as "install".
> So, you could then have something like:
> <screen role="install"><userinput>make install</userinput></screen>

Well, to be actually useful a package management support should be availlable 
while building BLFS packages.

Now think on how the BLFS XML layout will need be changed to add something 
like the above. That could require be done not only on "make install" 
commands, but also to each "mv ..", "ln ..", "cat ...", etc. to can track 
acuratelly all installed files.

> Then, during the command extraction during jhalfs, you could query for
> this role and define extra <xsl:text> actions that surround this text.
> This is really no different than what the paco patch appears to be
> doing now, except it's not hardcoding things by looking for string().

Yes, in theory that is a good method, not only for PM but also for other stuff 
and customizations.. But that implies that all book's sources will need be 
redone thinking on atomatization.

> Now, here's where I'm totally lost by not knowing xsl. I'd like it if
> the lfs.xsl script "included" something like pm.xsl where you could
> define custom actions that would be triggered for the "install" role.
> Basically, I think it would be preferable if the dumped commands
> contained all the extra processing instead of mangling LFS/
> to add commands to the Makefile.
> Is this possible?

For example, in LFS, for the unpack code we need to know what package nane is 
associated with each XML page. 

At bash level is easy to grep a packages list searching what package match a 
script filename.

At XSL level I can't find yet an easy way to do that. Maybe that could be 
implemented via key() and document() functions. The easiest way is to add the 
package name to the XML file that build it, like in BLFS. But again, that 
meant to change the book sources thinking on automatization.

At this moment we are working on a way to allow user to full customize the 
{C,H}LFS builds (BLFS builds are full customizables by default). 

The preliminar code to create configuration files and install additional 
packages after installing the base system (like packages required to acces 
the network or to support specific hardware) is in trunk.

Remain to allow to customize the base system packages. For example, to change 
a package version, to add extra patches, to replace one package by other 
(GRUB by LiLo, SysVinit by depinit, etc), or to insert new packages, like the 
one needed for the PM of choice, without having to edit a local book sources 
working copy.

When having that ready, a user will be able to hack the build in any way it 
would, included package management support. Of course, only "by the book" 
builds plus the current implemented desviations (ICA/farce and optimizations 
support) will be full automatized. The others hacks will need be made "from 
scratch" editing shell script files and makefiles, but after all this is the 
philosophy of LFS world ;-)

Manuel Canales Esparcia
Usuario de LFS nº2886:
LFS en castellano:

More information about the alfs-discuss mailing list