New Features for Profiles

James Robertson jwrober at
Sat Nov 27 17:41:19 PST 2004

Thomas Pegg wrote:
> 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.

I would like to see a 1a) to this - add the download element to each 
package so that if it is not local then it will get downloaded from a 
mirror.  Make the ftp mirror an entity that is easily changeable so we 
could have a local ftp mirror for example.

> 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