r7598 - in trunk/BOOK: . chapter01 chapter03
manuel at linuxfromscratch.org
Wed May 10 11:05:21 PDT 2006
El Miércoles, 10 de Mayo de 2006 00:56, Bruce Dubbs escribió:
> Since all the file sizes are on one page in LFS, why don't you just put
> all the sizes in general.ent as entities like the version number and
That is what CLFS is doing in a separate packages.ent file to avoid to have to
edit the several packages.xml files they have on each package update. For
<!ENTITY bash-version "3.1">
<!ENTITY bash-size "2.4 MB">
<!ENTITY bash-url "&gnu;bash/bash-&bash-version;.tar.gz">
Remember that in CLFS there is no SBUs nor disk usage data.
I would to implement that also in LFS and HLFS, but first we need to
figure-out what to do with "Home page" links, due that some packages don't
If we left Home links "as-is" in packages.xml, editors could to forgot to
If we create an entity for Home links, we will have some empty links; or an
XSL hack will be required to skip the full para when the entity is empty.
Actually, before to can propose the addition of Home links and MD5 sums into
CLFS I need to have ready the XSL hack.
As Matthew said, there is no technical reason to create that entities due that
they are used only on one place.
But IMHO, having all that data centralized on an unique file could to do more
easy packages updates and will produce more clean svn commits.
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.com
More information about the lfs-book