Use of Entities in the cross-lfs book

M.Canales.es manuel at linuxfromscratch.org
Tue Jun 21 11:21:27 PDT 2005


El Martes, 21 de Junio de 2005 01:56, Archaic escribió:

>
> A hybrid of something like BLFS does might be nice. However, I don't
> like the idea of having package-specific entities spread across multiple
> files. Here's an idea for a packages.ent (or even left in general.ent)
> file:

To place entities on the files headers isn't a good idea for LFS, IMHO.

I think that Jim is proposing that new packages.ent to can do packages 
updates, when no commands changes are needed, editing only the *.ent  and 
changelog files.

> <!-- Package 1 -->
> <!ENTITY package-version "2.59">
> <!ENTITY package-size "2.3 MB">

<!ENTITY package-url "http://url/to/package/official/download"

> <!ENTITY package-buildsize-x86 "81 MB">
> <!ENTITY package-buildsize-ppc "81 MB">
> <!ENTITY package-buildsize-x86_64 "81 MB">
> <!ENTITY package-buildsize-mips "81 MB">
> <!ENTITY package-buildsize-sparc "81 MB">

Some packages, like Glibc and GCC, will require several blocks like that, one 
for each time that the package is builded.

> <!ENTITY package-time-x86 "0.3 SBU">
> <!ENTITY package-time-ppc "0.3 SBU">
> <!ENTITY package-time-x86_64 "0.3 SBU">
> <!ENTITY package-time-mips "0.3 SBU">
> <!ENTITY package-time-sparc "0.3 SBU">

The same here, if want SBUs for pre-final-system packages.

> <!ENTITY package-patch_name-patch "package-&package-version;-foo-1.patch">

Not sure about this. I see more easy to handle patches agrupped by arch, like 
they are currently in patches.ent.

Also, we don't need to declare the new packages.ent file on each XML file. Is 
enouch declaring it in general.ent (the same is valid for patches.ent).

In general that look like a good idea. Could do more easy simple packages 
updates.
 

-- 
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
TLDP-ES:                           http://es.tldp.org



More information about the lfs-dev mailing list