[RFC] Potential nALFS enhancements to {unpack}/{patch} elements

Kevin P. Fleming kpfleming at linuxfromscratch.org
Fri May 21 15:38:09 PDT 2004


Forgive me for thinking down the road when I don't even have time to get 
CVS fixed today, but I've been letting this run around in my head and 
thought I'd get everyone's opinions on it.

I'd like to offer some new functionality for the {unpack} (and {patch}) 
elements, that would consist of two parts:

- the {file} child element would be optional. If not specified, 
{reference} element(s) must be specified, and {digest} would not be 
allowed, because in this no-{file} mode, the downloaded contents would 
be piped straight to the unpacker (or patch), no local copy of the file 
would be made.

- the {reference} element would gain support for two new URL types 
(implemented in nALFS itself):

file://path/to/file would do the obvious thing, just copy that file from 
the given path to its destination (or directly to the unpacker)

host://path/to/file would be really slick: it would actually pass the 
path to the _frontend_, which would digest-check, open the file and 
stream it to the backend. Applications for this would be (at least): not 
needing to copy the tarballs/patches into a location inside $LFS, 
allowing ftp:// and or http:// URLs to work _inside_ the chroot 
environment, and when nALFS can be run split across two machines you 
would not need to copy all the tarballs/patches onto that machine before 
running the profile.

Thoughts?



More information about the alfs-discuss mailing list