Managing required packages in nALFS

Neven Has haski at sezampro.yu
Sat Oct 5 09:39:24 PDT 2002

On Sat, Oct 05, 2002 at 12:18:56AM +0200, Vassili Dzuba wrote:
> When using the patch, the stamp file is created in the chrooted
> environment, and the log file outside of it.
> There is however an advantage to this : if you have several chrooted
> environments, or build the packages both in the host distribution and
> in a chrooted environment, the log files are all written in a single
> directory, but the stamp files are written in the chrooted
> environment, and are deleted if you erase the corresponding partition.

Good point. All these log files probably shouldn't be on the frontend's
side at all, but backend's (always thinking about separate frontend and
backend). So the fronted would just collect that info from the backend,
so he can inform the user.

All in all, that stuff needs rewriting somewhere in the future. :)

> It seems rather difficult to do that in general as the "greater than"
> relationship on version numbers is rather difficult to define
> precisely as various packages use different numbering schemes.


> To do that we will need to define a small expression langauge, and
> somebody will need to implement it ;-)

Oh, so we have a volunteer. Great. ;)

> BTW, the BLFS Book doesn't try to describe the dependencies using the
> minimal version number, but uses the version number of used to build
> the package in the book. Maybe it could be enough in a first step.

Yeah, we can make it really simple at start, since the syntax is
already constantly evolving.

> What do you think of :


> <!ELEMENT depends-on  EMPTY>

I think I remember that we were trying to remove all '-' and '_' from
element names in the "final syntax" (heh, that word has lost its meaning
completely), so I would prefer just <dependency>. Although Seth's
<requires> sound nice too.

> <!ELEMENT utilizes    (#PCDATA)>

What's this for? Some optional packages that might be utilized if they
are installed? Do we really need something like this?


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