About packagemanagment: dependencies.
markus.mahlberg at web.de
Mon Jan 3 03:56:27 PST 2005
Stef Bon wrote:
> 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
> 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
> Now my idea is, isn't is possible to let the script "configure" do this
> 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?
> (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
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.
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.
More information about the alfs-discuss