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/master.sh
> 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: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
