Managing required packages in nALFS

Vassili Dzuba vassilidzuba at
Fri Oct 4 15:18:56 PDT 2002

On Fri, 4 Oct 2002 14:51:19 +0000 (UTC)
haski at sezampro.yu (Neven Has) wrote:

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

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

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

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

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.

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

What do you think of :

<!ELEMENT package (packageinfo?,stage+)>
<!ATTLIST package
          name           CDATA #REQUIRED
          version        CDATA #REQUIRED>

<!ELEMENT packageinfo (depends-on*, utilizes*)>

<!ELEMENT depends-on  EMPTY>
<!ATTLIST depends-on
          package     CDATA     #REQUIRED
          version     CDATA     #REQUIRED>
<!ELEMENT utilizes    (#PCDATA)>
<!ATTLIST utilizes
          package     CDATA     #REQUIRED
          version     CDATA     #REQUIRED>

(the book uses the expressions "depends on" and "will utilize")

This DTD of course doesn't try to solve the problem of the version checking
as we may put very different things in the attribute "version".

> 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