Managing required packages in nALFS

Neven Has haski at sezampro.yu
Thu Oct 3 05:50:13 PDT 2002

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?

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.

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

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

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

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.

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

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


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