Managing required packages in nALFS

Neven Has haski at sezampro.yu
Fri Oct 4 07:52:43 PDT 2002

On Fri, Oct 04, 2002 at 12:08:03PM +0200, Vassili Dzuba wrote:
> > Wouldn't it be better to use the presence of a build log for a
> > particular package to determine if it was installed, rather than an
> > arbitrary <stamp> element ? Or better yet, add a status of some kind
> > in the log. Then implement that <packageinfo> idea from a while back
> > containing <depends>, <requires> or whatever.
> The build log exists even if the build of the package failed and the
> package had not been installed.
> Adding a status in the log would work but it's a little more
> complicated. As the two functions (log vs dependency check) are
> different, i don't see any problem with having separate log and stamp
> files. It allows to see the list of installed packages with a simple
> "ls" (but of course a grep on the log files is not very complicated
> either).

As Mark said, having the separate stamp file just for dependency
checking is really duplicate information. I agree it's easier that way,
just checking for the presence of file, then to actually open it and
check its content.

However, a parser could read those files as soon as it's started and
maintain the list of packages installed/failed/etc., updating it as it
runs. That would make the checking even more easier and faster. And it
shouldn't be really a memory issue either, if we use just name and
version of a package to identify it.

Also, that info can be used latter, to print the list of packages
installed from the program and other interesting stuff like that.

> The <check> element is a very minimal way to describe the dependency,
> and we surely could do better.

Yeah, for starters, we need to add a version to it. And not just a
simple "package needs version 1.2.3 of foo", but also "package needs
version greater than 1.2.3 of foo" and similar.

We have to discuss the format of some "<dependency>" element (or
whatever). Well, we already did that, but we also have to actually end
that discussion. ;)


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