Package Management Options

Dan Nicholson dbn.lists at
Tue Oct 17 14:08:52 PDT 2006

On 10/17/06, <manuel at> wrote:
> El Martes, 17 de Octubre de 2006 20:00, Dan Nicholson escribió:
> > 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.

Maybe I'm in the minority, but I think that's a useful goal. To me, it
seems like most of the editors are just following XSL convention
anyway. I.e., in BLFS we're adding role="root" because somebody said
to do it. If we were to start saying add role="install" and did the
initial mass changeover, I don't think anyone would have too big a

> > 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.

Could you point me to some XSL documentation? Maybe some newbie level
stuff, too? This is my major stumbling block in mapping between book
and build. You guys are doing kick ass work on jhalfs, but I think
there's some lower level work that could be done to make it more
powerful without requiring lots of workarounds at the higher level.



More information about the alfs-discuss mailing list