Patch for nALFS
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
> > 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
> one for static bash - it is also possible to enable logging of "what's
> done" messages, added between "started" and "ended" times. (Now would be
> 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:
> <version something="describing needed relation to this version">
> 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
> > > with current profiles. And adding is_new_new_syntax() (god forbid ;)
> > > 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
> > > By that time, we should also have a good "converter" between
> > > syntaxes (you seem to make a good progress with XSLT for example),
> > > 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
> > I have some visions of a database which contains all the infos for the
> > It could be feed from the book via xslt, from freshmeat (versions,
> > 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. :)
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