About packagemanagment: dependencies.

Stef Bon stef at bononline.nl
Mon Jan 3 03:24:54 PST 2005

Markus Mahlberg wrote:

> Stef Bon wrote:
>> Hello,
>> I'm interested in developing the nAlfs packagemanagment utility.
>> Now I see that one of the things to be developed is the ability to
>> show the dependencies of a package.
>> Now I saw some comment suggesting a database with only the basic
>> dependencies.
>> This sollution is often used. Red Hat uses such a database for their tool
>> rpm. I've been looking (a little) at Gentoo, at their emerge/portage
>> system, but this also is based on a database system.
> Hm , I personally don't see the problem. Afaik RPM brings it's own
> version of BerkleyDB with it, so there would be no need for additional
> packages other than RPM. Another advantage is that you can use rpm -ba
> for building the packages up to a point where it can be a replacement for
> nAlfs. I work on sth like that, though it I experienced some big
> disadvantages (time-consuming builds, problems with error-handling and so
> on)
>> Now my idea is, isn't is possible to let the script "configure" do this
>> work???
>> In the configure script (and the configure.in file) al the dependencies
>> are there already. This information you (I do) are using when installing
>> a package, and configure complains about a missing required other
>> package.
> It does, but I can't see how this is related to package management. To let
> an configure-script handle the installation of other packages doesn't seem
> the best idea to me - how would the configure script find out an
> dependency of a dependency? How could configure handle recursive
> dependencies?

I think there is a litlle misunderstanding.
I suggest using the information of the configure script and the configure.in
file to build the database. That's my idea. Not as a replacement of this

When I think of building this package-dependencies-database it looks like a
lot of work to me. To determine the dependencies by hand for every packet
and every new release. 

My idea is to make a new tool ( call is autodepdb for example)

and run it in the source directory:

cd /path/to/source/of/program-1.5


this adds (or renews) information of program with version 1.5 
to the local(?) database, with all the information about the dependencies
(required and optional) with it.

I was wondering it is possible. All the information needed is in the
configure script and related files, as I've earlier said.

I do not suggest to let the configure script do other things.
Other tools are ther to query this database, like viewing all the installed

Actually I don't know how these database are build at this moment. 

>> (not only this information is important by the way)
>> I'm not familiar with the auto-tools (aclocal, autoconf, automake etc)
>> but does anyone know what they can do?
>> I know there are a few drawbacks I can alreadty think of:
>> . not all the packages use a configure script
>> . using configure takes a lot of time
>> But advantages:
>> . databasa realy uptodate
>> . manual creating the database not needed
>> Any suggestions, idea's
>> Stef
> Package management became an issue for me as I am convinced of the purity
> of an (B)LFS system - no redundant configuration tools, no packages you
> most likely won't ever need aso. I started a project using RPM to install
> an LFS-based system for myself, now my new employer is quite interested in
> that projects and kind of sponsors it. We reviewed the tools available and
> found out that we didn't have to reinvent the wheel - there are RPM and
> DBPK, which both met our requirements. The decision for RPM was made
> because we felt more comfortable with RPM's spec files.

This is the first time I've heard about using RPM as a tool in the ALFS

You talk about RPM as a good tool, for what? Is this your own project or is
this for nAlfs?

> Bottom line to us was that using existent and well doumented tools is
> easier than to reinvent them.
> If I could be of any help or you are interested in participating in our
> project, get back to me.
> Regards,
> Markus

More information about the alfs-discuss mailing list