[lfs-dev] Latest packages

Matt Burgess matthew at linuxfromscratch.org
Fri May 3 23:57:29 PDT 2013

On Fri, 2013-05-03 at 21:54 -0500, Bruce Dubbs wrote:
> 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?

The furthest I got was producing
http://www.linuxfromscratch.org/~matthew/lfs_packages.html From there, I
did intend to write a script to automate what I currently check
manually, but never got around to it.  Given the issues you outline
above, the way I would probably approach this is for the script to save
the contents of each of the 'directory listing' style URL (the one
pointed to by the hyperlinks under the 'Package' column in the above
link) and save the contents somewhere.  Then, the following day, save
the contents of the same URL again somewhere else, and do a diff between
them.  You'll need some 'smarts' in there to ignore diffs between
automatically generated dates, and such like, that no doubt exist in at
least some of those pages, but overall, I think that approach would be
more consistent across all the LFS packages than trying to parse each of
the download location listings individually for updated package



More information about the lfs-dev mailing list