Patch for nALFS

Mark Ellis mark.uzumati at virgin.net
Mon Dec 17 15:24:33 PST 2001


On 2001.12.17 18:34 Paul Campbell wrote:
> > <unpack>
> >     <archive type="local">
> >         /usr/src/packages/ed-0.2.tar.bz2
> >     </archive>
> 
> >     <archive type="remote">
> >         ftp://ftp.linuxfromscratch.org/lfs-packages/3.1/ed-0.2.tar.bz2
> >     </archive>
> 
> >     <destination>/usr/src</destination>
> > </unpack>
> 
> And where prey tell will it put the package when it's downloaded?
> 
> What will happen if you have a modem and you lose the connection in the
> middle?
> 
> What would happen if it was too big to download in one go, say the
> kernel, for
> example, it is very near to my download limit on one connection. ( I have
> 2 hour
> timeouts on my ISP )
> 
> I don't think that the program should do this on the fly, it would be
> slow and
> inefficent waiting for packages to download, when they could be done in
> parallel with other builds.
> 
> What would work is for the parser to analyse all the package <archive>
> elements
> first, compile a wget list and ask you about starting the process.
> 
> I also think this fits more with my META ideas, ie. stuff that is not
> really
> used by the parser, but by the user of the profile for reference.  A perl
> script to create a wget list from the profile would be very easy, and
> alfs
> need not be modified and over complicated.
> 
> Make any sense?

Makes sense, but I think we need to really sort out what we're doing 
before acting on any of this. There has been a lot of discussion lately 
about automated downloads, meta information, package dependencies etc., 
and it seems this is because we've at last last reached the next stage in 
ALFS. We have a good syntax for building and two implementions for using 
it, and now the fun ideas can get going, but none of these are just a case 
of following a set of instructions in "insert your language here", in our 
case XML.

For instance, with download on demand, where do we put the package ? In a 
temp directory, then delete it ? In an archive directory ? If the latter, 
is this directory specified by the application or the profile ? Maybe 
either, so we could specify <archivedir>default</archivedir> or a custom 
dir ? In that case, maybe we don't need the full path in unpack for a 
local package, just look in the default if the path isn't absolute ? Am i 
making sense :)

I want to emphasise at this point that none of the above are necessarily 
how i see it working, that is just an example of how complex some of the 
areas we're approaching could be.

So where do we go from here :) Hey its coming up to christmas, there are 
too many things in my head to figure this out now :) Okay, how about we 
start off by figuring out what kind of information we can put in the 
profile that we actually need, or that might be useful. I like Paul's idea 
of meta-information, maybe not to the extent of comments, that's what 
READMEs are for, but for a start :-

download url
brief description
web page ?
dependencies

The description is nice and friendly, web page in case down the line we 
get to the stage of launching a browser, and download url for the 
aforementioned auto download. I did at this point think should we have 
version in the profile, but since build requirements may change between 
versions i suppose we'd better profile for specific versions. So we get to 
an unpack, what do we do ? I dont think it makes sense to automatically 
download something we already have, so where do we check ?

My head is starting to ramble to me, so i'll wait for feedback before 
getting any more tied up :)

Mark
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list