On 06/08/2011 07:11 PM, Michael Schroeder wrote:
Does anybody know/remember what those config() dependencies
are good for? They were added back in 2002(!) by commit e788b7c1.
I see that a package gets a
Provides: config(N) = EVR
if it includes a config file, but why is that also added as Requires,
as the require is always fulfilled by the package itself? Why would
another package require that a package contains a config file?
The config() dependencies were supposed to be a part of a mechanism to
allow cleanly replacing configuration of another package, briefly
described by JBJ here:
http://www.redhat.com/archives/rpm-list/2003-March/msg00354.html
It's just that the "some dependency magic" and other necessary bits were
never actually implemented, perhaps because the idea has some holes in it:
Suppose you're an admin preparing distro X for company internal use, and
you have a distro package "frobserver" which includes some configuration
that you'd like to replace by a default configuration to match your
company's network/environment. So you create a "frobserver-myconfig"
package which provides config(frobserver) and install "frobserver" and
"frobserver-myconfig" with --noconfigs and, err, ...profit! The "missing
dependency magic" means --noconfigs doesn't make "frobserver" NOT
provide config(frobserver), so the config() dependencies dont actually
do anything. And even if they did, using --noconfigs means the config
files from "frobserver-myconfig" wont get installed either, or you'd
have to originally install "frobserver" with --nodeps. Oops.
I haven't killed the config() dependencies partly because there's a
chance somebody is using them for their own purposes (whatever they
might be), partly because the ability to cleanly replace config of
another package has been one of the most frequently asked questions on
rpm-list and technically it /should/ be possible to salvage the idea, it
"just" requires
- Changing --noconfigs (and similar while at it) flags to be per
transaction element rather than transaction global, and somehow making
it possible to meaningfully use this from programs (rpm cli, depsolvers)
- Taking --noconfigs into account for dependencies, so that installing
another package would be required to satisfy the config(foo) requires.
Which could be done runtime on rpm level, but falls flat in this world
where depsolvers perform dependency resolution on "static" repository
metadata.
There's a use case for a config() provides without the N,
we have a perl script that checks if there are any unresolved
(.i.e. .rpmnew...) config files. It would be much faster if
the search could be limited to all packages that contain config
files. With config(N), I could use the new IndexIterator to
find all config(*) provides, then query each of them for
packages.
Yup, with the index iterator this should be plenty fast enough.
Overall, %config files handling of rpm is pretty primitive. What seemed
"pretty neat" 10+ years ago now looks just like technology from last
century - which of course it really is. These days, folks are expecting
intelligent merges, actual change tracking and integration with system
management software (puppet, cfengine etc).
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
