New Features for Profiles
jamie_bennett at pcpmicro.co.uk
Fri Nov 26 07:51:40 PST 2004
Kevin P. Fleming wrote on 26 November 2004 15:54
> Jamie Bennett wrote:
>> The unpacking based on file extension is also a good idea and would fix
>> many a newcomers problems. Looking back through the mail archive there
>> references to people using the wrong tarballs so I think this is again,
>> sufficient enough excuse to add it.
> If you do this, the profiles will become incompatible with all previous
> versions of nALFS, and all other ALFS tools. The download/unpack
> elements will no longer have complete file names specified, and thus
> won't work without this modified version of nALFS.
Why? We could do a fall back method which could, if the original file wasn't
found, look for a file of the same name with a different extension. I'm not
saying it _should_ be done, just that it could be done and would save the
hassle of a build bombing out half way though due to a tarball having the
wrong extension but see my next point ...
> My vote is this: don't do it. We are not in the business of making
> things "point and click" easy for newbies who can't read the README
> files and ensure that they have the packages that match the profile. We
> even give them a wget script, for pete's sake :-) Yeah, my opinion is
> harsh, but I'm personally not thrilled about the number of people who
> download nALFS and a profile and don't have any clue at all about what
> it's doing for them.
Ok Agreed. A good (IMO) compromise could be to add the --download-only
option which could be run to get the files and digest check them and
ultimately ensure that we are all clear to proceed with the build.
Implementation wise it would just execute the (download) tags and any
(reference) tags inside of (unpack).
More information about the alfs-discuss