Patch for nALFS

Neven Has haski at sezampro.yu
Tue Dec 18 06:38:14 PST 2001


On Mon, Dec 17, 2001 at 06:34:07PM +0000, 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?

Locations with type="remote" could be handled differently. Files could be
stored in some default (and configurable) directory and connection problems
could be also handled nicely.

> 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.

But this is the real problem.

We could implement it nevertheless, and it could be only used in rare cases,
like a fall through or something. But I agree it's not for the standard use,
for the reasons you mention.

> 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?

Yes, that would probably be better. I don't thing that analyzing <archive>
elements would be very clean solution, it might be better then to just
specify that <download-url> or something, somewhere below the <package>.

I also like putting all that "meta" information in the element of it's own.
I always get a funny feeling after adding even <version> and <name> on
the same depth level as <build> and friends. It doesn't seem natural to
me. This is something that Felipe is also suggesting - separating all that
info from the building instructions (maybe not by using <meta>, we might
need something more descriptive) could be nice.

But this would be a big syntax change again, because it's incompatible
with current profiles. And adding is_new_new_syntax() (god forbid ;) or
is_syntax_version(3) would make me (and probably Mark) very unhappy. ;)

I'll start writing ideas like this, so maybe in the future when we have a
pile of them, we could switch to syntax 3.0, quickly and less painfully?
By that time, we should also have a good "converter" between different
syntaxes (you seem to make a good progress with XSLT for example), making
the change easier in that way too.


Neven

-- 
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