[lfs-dev] Latest packages

Pierre Labastie pierre.labastie at neuf.fr
Sat May 4 02:04:00 PDT 2013

Le 04/05/2013 04:54, Bruce Dubbs a écrit :
> I'm going to write a program to automatically identify out of date 
> packages for LFS.  Has anyone already done such a beast?
> As I review the packages, it seems that the only constant is 
> inconsistency.  Trying to parse versions is quite package specific. 
> Packages may have versions with a single number (systemd, kbd, less), 
> two numbers (vim, psmisc, etc), three numbers (most), and even four 
> numbers (shadow).  In one case, the version has a letter (tzdata).
> Some packages change the version scheme depending on release 
> (util-linux-2.22.1 vs util-linux-2.23, gcc, linux kernel, etc. )
> In addition, some directories that contain the packages vary with 
> version (e.g. v2.23/util-linux...,  check/0.9.10/...,  gmp-5.1.1/..., 
> 1.0.6/bzip...,  mpfr-3.1.2/... ).  Some sites don't allow a directory of 
> the parent location so other means of determining the most recent 
> version are needed (e.g. bzip2).
> Some directories change infrequently (kernel v3.x,  5.0/perl...)
> Sourceforge is generally a PITA because they do a lot of redirection 
> which changes with version (prdownloads.sourceforge.net vs 
> sourceforge.net/projects etc).
> When parsing a package filename for version, some packages have version 
> numbers embedded (bzip2, iproute2, tcl8, e2fsprogs, expect5).
> Some package names have dashes (man-db, pkg-config, procps-ng, iana-etc).
> Writing a script to do all this is not particularly hard, but just long 
> and tedious.  There are some common elements in most of the packages 
> from ftp.gnu.org.
> Has anyone else looked at this?

Not sure it is helpful for what you want to do, but I have met some related
difficulties for the ablfs projects (extension of jhalfs to BLFS):

Actually, some BLFS packages have added problems compared
to LFS (think of CDParanoia-III-10.2 or PSUtils-p17, for example). So I decided
to follow what the BLFS devs considered as being the name and the version fields,
using what they put in general.ent:
There are <!ENTITY xxx-version "vvv"> fields which indicate what the dev had
in mind concerning version for package xxx. However, xxx is not the name
of the package, it is the id of the page in the xml book. You can then retrieve
the name of the package from the xreflabel attribute in the sect1 tag.

For the LFS book, you may use packages.ent to achieve the same goal. I guess
you could obtain the version from the xxx-version entity, and the name of the
package out of the xxx-url entity.

Now, when fetching a tarball name from a repository, you may extract the name
and be left with the version, whatever it is.

I have also an xsl template for comparing versions, which has not yet failed
for BLFS packages, but I have not tested all of them. And I do not like
very much what I have done, it is very convoluted...


More information about the lfs-dev mailing list