Patch for nALFS

Mark Ellis mark.uzumati at virgin.net
Wed Dec 19 11:38:59 PST 2001


On 2001.12.19 17:51 Neven Has wrote:
> On Tue, Dec 18, 2001 at 05:53:13PM +0100, Martin Imobersteg wrote:
> > How we could handle dependencies ?
> > Some time ago i have done a Makefile to build an lfs.
> > I touched a file in a dir ( ex: touch /var/log/installed/libfoobar-0.18
> )
> > and checked for its existence.
> > This approach could be used by nALFS in touching a file
> <name>-<version>
> > in a standard dir.
> 
> I did something like that already:
> 
> After installing each <package>, you'll end up with
> ~/.nALFS/packages/<name>-<version>.log files. As an example, I attached
> the
> one for static bash - it is also possible to enable logging of "what's
> being
> done" messages, added between "started" and "ended" times. (Now would be
> a
> good time for someone to tell me how much this sucks).
> 
> I wasn't playing with dependencies yet, but that file could be also used
> for them, as you suggest.
> 

Working on this too, absolute pig of a job :) I presume you're doing a 
find before and after and comparing the results ? Your output looks good.

> > I think the solution of Felipe with a
> > <depend>bonobo>=0.18</depend> tag is ok, but i see some problems with
> the >=
> > cause there are some realy ugly versioning models around :-(
> 
> Yes, and there is a problem with > too. ;)
> 
> But seriously, something like:
> 
> <dependencies>
>     <package>
>         <name>foo</name>
> 
>         <version something="describing needed relation to this version">
>             0.18
>         </version>
>     </package>
> </dependencies>
> 
> could be used for example. I don't know if there is some other info that
> should go in there.
> 

Nothing else springs to mind, the only problem is the versioning schemes 
of packages, as mentioned before.

> > > 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.
> >
> > What about a unstable version to implement such things. It would be
> cool if
> > we can test the things before we release a new syntax.
> 
> It would, but then we definitely need some better syntax versioning (from
> the parsers view). Otherwise, we would end up with a bunch of ifs in the
> code, which is extremely prone to errors and, needless to say, ugly.
> But that's a different problem, for program writers (*grumble*).
> 

We could always go the route of ignoring tags that aren't yet implemented, 
as long as the syntax structure doesn't change fundamentally, which was 
the problem with the old -> new change. Not ideal i know, but i think it 
is easier to introduce things to the new syntax than it was in the old 
version.

> > I have some visions of a database which contains all the infos for the
> xml's.
> > It could be feed from the book via xslt, from freshmeat (versions,
> package
> > description ) and a web frontend.
> > Then you could go and click your system together with all the available
> 
> > packeges, type in your ip, hostname and stuff and download it to your
> > pc. alfs would build it for u - et voila, your brand new system :-)
> > Dream on ...
> 
> If ALFS should have some ultimate goal, that would probably be it - part
> of the famous "LFS InfoSystem", if I remember correctly. :)
> 

Drool... :)

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