[Rpm-maint] config(N) = EVR dependencies

Panu Matilainen pmatilai at laiskiainen.org
Thu Jun 9 06:42:11 UTC 2011


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 -


More information about the Rpm-maint mailing list