Managing required packages in nALFS

Vassili Dzuba vassilidzuba at
Thu Oct 3 14:22:57 PDT 2002


On Thu, 3 Oct 2002 12:48:55 +0000 (UTC)
haski at sezampro.yu (Neven Has) wrote:

> On Sun, Sep 29, 2002 at 10:03:32PM +0200, Vassili Dzuba wrote:
> > AFAIK, my patches don't break anything, but i'm not sure they are
> > "production quality" either.
> Just a few questions/comments...
> I haven't included patch #1, for now. It would be nice to have something
> like that, but as you said in one of your emails, the best way would be
> to have totally separate handlers for it. Everything else would just
> have to be messy and all over the place. :)


> Is there a reason for defining MARKS_IN_COLOR and DISPLAY_TIMER as 1.
> I mean, it doesn't matter how they are defined, I'm just curious if
> you had some problems with them maybe, or something like that?

no, i just wanted to test what they did, and forgot to set them back
to the original value.

> In ~/.nALFS/packages directory, the log files describing the packages
> that have been installed are stored. There is probably room for some
> improvements in the way that's done, but I think we should use those
> instead of creating another stamp file in /var/log/nALFS. Well, the
> directory in $HOME is wrong, the better place would be what you used.
> Although I would go for /var/log/ALFS and standardizing the files'
> format, but that's another story.

The idea of the stamp file was to be able to only check the existence of 
the file, without needing to open it. The log file will exist even if the 
build fails, so we would need to open the file to know if it succeeded.

Now, I agree that it would be better to have everything in the same 
directory or in siblings directories.
I put them in /var/log because of the chroot problem, 
as you mentionned below.

> <check> would have to be coded a bit differently, with lots of help from
> a frontend. He (the frontend) is the one (for now) that has the
> information about mentioned installed packages and he's the one that has
> to update those stamp files (solving that chroot problem in the
> process). Also, he's the one that has to follow what the backend does,
> so he can inform the user about it. It shouldn't be too hard to do it
> with adding a few new control messages.

yes; the patch doesn't even try to inform the user interface of the success 
or failure of the build of dependent packages. I didn't delve in the code 
enough to do it through the frontend.

> Code for building required packages was crashing on me (probably because
> of some of the above reasons, since the backend it doing too much on its
> own), with this profile (with -S -B options and without any files in
> /var/log/nALFS):
> <alfs version="3.0">
>         <package name="test" version="1.2.3"><check>bash</check></package>
>         <package name="bash" version="1.2.3"><execute command="ls"/></package>
> </alfs>
> so for now, I have commented that part out. But I left the stamping (in
> /var/log/nALFS for now) and <check>ing for required packages.

I'll try to rewrite the patches more cleanly when your new version
will be available.

> And I have included <reference> (check out the TODOs).
> I want to release the new version ASAP, so we can continue from there.
> > For instance, I didn't look very carefully at the command interface
> > so that the patches are activated only by a parameter in the command line,
> > but cannot be activated when running the application (or, if they
> > can it's without my knowledge...).
> No, some extra work has to be done, but that can always be added latter.
> > There are a few more  patches that i would like to implement (or see
> > somebody implement):
> That would be great. :)
> > - a conditional execution (with  a tag <if>)
> I was always a bit skeptical about that <if>. We've been talking about
> something like that for a few times on the list already, but never did
> anything about it. I guess the best thing would be to actually see it in
> action.

I would like that we could run a profile for a basic installation (but larger
than the LFS) with the only customization done in the 'general' file.
For instance, the user will need to be able to choose between a static 
allocation of IP numbers or DHCP. My router seems to insist that i use DHCP
(i was never able to access the internet using statically allocated IP numbers).
This is one case where i would like to have a <if>.
SGML used to give such fucntionality using marked sections, but this was dropped
in XML that kept only <![CDATA[.

> > - a attribute or subelement of <unpack> that contains the checksum of
> > the archive, so that we could check its validity befor unpacking
> That's a good idea.
> > Recently, i have been occupied mostly with writing a BLFS profile (it
> > contains about 100 packages now).
> That sounds nice. :) We desperately need a single "profile archive"
> somewhere. There are a few sites where people have their own profiles,
> but it's all scattered around and not organized well.

Well, would be nice for that...

> Neven
> -- 
> Unsubscribe: send email to listar at
> and put 'unsubscribe alfs-discuss' in the subject header of the message

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

More information about the alfs-discuss mailing list