New Features for Profiles

Thomas Pegg tom.pegg at
Thu Nov 25 20:51:20 PST 2004

On Thu, 25 Nov 2004 20:23:37 -0500, Jeremy Huntwork <jeremy at> wrote:
> Hello all,
> Just wanted to put forward a few new features I'd like to see
> implemented into the current nALFS profiles, if there are no objections.
> 1) I'd like to move all the packages that the profiles expect to use in
> the config_separate dir to bz2 format. First of all, it makes it
> consistent and limits the possibility of mismatch between what you've
> actually downloaded and what the profiles expect. Also, since we have at
> least 2 fast and reliable ftp servers that house all our packages (in
> bz2 format) it makes sense to me to use those as primary download
> locations and make our profiles match. If there are any files that
> aren't released as bz2, of course we can re-compress them and produce
> our own new md5 sums, as I believe the ftp mirrors already do.

That would be great. I know that Kevin proposed to start using the FTP
mirrors a while back (on the website list I think), his biggest
concern was bandwidth usage I believe. But really the amount of
traffic ALFS would generate I think would be small, compared to LFS.

> 2) There are many I've talked to that *always* remove the md5sum feature
> from the profiles.  While I think it's good to leave them in by default,
> I'd like to see at the very least a note in the README that provides a
> sed command to remove the <digest> tags from the profile, and at most, a
> shell script included to do that.  In this way I hope to make it
> *slightly* more optional to make use of the md5sums

That one will be easy, I know I've got an old sed lying around here
somewhere that did just that, a shell script would be even better.

> 3) I'd like the profiles to support parallel building, that is, passing
> the -j flag to make. We could make a new entity in general.ent that
> specifies the parallel build level and have it set by default to "".
> Then, for all packages that are known to build sucessfully with a
> reasonable parallel level (2-3 x the number of processors in the
> machine) we can include param tags encasing the entity.

I think I'll let you handle this one, I don't know a whole lot about
parallel building. But it otherwise sounds like a good idea.


More information about the alfs-discuss mailing list