Re: [Helidelinux-devel] Dependency management for software packaging

[Bennett T. <be...@ra...>]

2004-03-09T04:50:54 Rolf Veen:
> On the other hand, once dependency info is generated for
> a package/version, it is stable.

Mostly. On my systems, /usr/sbin/sendmail is provided by postfix; on
other peoples' systems it'll be provided by qmail, exim, or even
(horrors!) sendmail. Red Hat built in provisions for manual
provides/requires dependancy tagging for a logical role like "mta",
which fixes that problem, but AFAIK that's the only place it was
ever used; it ended up being yet another little one-off hack,
complicating the package manager while going almost entirely unused.
I reject that solution.

Instead, I want the dependancy data to be the best that can be
heuristically automatically computed, and have it advisory (knowing
it will sometimes be wrong) rather than mandatory. I may be wrong,
but I do know what I want:-).

> [...] That is, once generated, it can be published on a website
> and used by others. [...]

Now that is an interesting proposal, one I hadn't thought of before.

Given a packaging system like bpm, the dependancy data, both
build-time and install-time, will be included in the bpms, so
exporting them to a repository will be straightforward to automate.

> - how do we handle optional deps

I plan on associating the deps with the package build, and I encode
all option picking in the spec file, I don't use options or envars
to bpmbuild to influence the build process. I want the specs to
completely document how the package was built. At the moment it's
imperfect, since it doesn't mention all the packages that constitute
the build env which of course influences the built package
(including in particular optional features that are auto-detected).
Once I tackle dependancy management that will take care of that bit.

> - what are the basic units: packages, files.

Packages. The lists in build-dependancies and install-dependancies
will be lists of package names. Files that exist on the system but
don't belong to any package are not counted. Only the packages that
own the files will be counted. One thing I'm still pondering is
whether to ignore files whose checksums don't match the checksum in
the sha1 manifest of the package that claims to own them. I'm
inclined to in fact ignore such broken package ownership claims.

-Bennett