[Rpm-maint] Pruning self-dependencies?

Panu Matilainen pmatilai at redhat.com
Fri Jul 6 07:36:36 UTC 2007


On Mon, 2 Jul 2007, Ville Skyttä wrote:

> Hello,
>
> Is there a good reason why packages "export" dependencies on things that they
> Provide/satisfy themselves?  For example, if a package ships/provides
> perl(Foo) and has some other things that also cause a dependency on
> perl(Foo), wouldn't it be a good idea to just prune the dependency at build
> time and not include it in the package's dependencies?  Pruning it would
> result in less dependencies in rpmdb, repository metadata etc etc.

I've been thinking about this like, um, forever - why on earth do packages 
depend on themselves (through various means)?

> The only case where I can see potential use for a self-dependency is that
> let's say my package foo needs something that is provided by a "virtual"
> package/Provides bar.  foo also includes an implementation of bar, but a very
> basic one, and there are other packages out there that include
> superior/alternative implementations of bar and Provide it.  Now, I
> have "Requires: bar" in foo, and when installing foo, depsolvers could
> present me a list of everything satisfying bar (including foo itself) and
> give me an option to choose one of them.  I think this is a pretty
> hypothetical case; are the depsolvers out there that would implement
> something like this?  apt at least used to list alternatives for a Provides,
> but what if the set of packages going to be installed anyway already satisfy
> it?

No manually added dependencies should be pruned to avoid killing virtual 
provides. Also rpmlib injected config(foo) dependencies need to be left 
untouched as the config can be provided (in theory) by something else. But 
for automatically extracted soname dependencies I think it would make 
perfect sense to prune out self-requires.

Like Bill mentioned, this would cure a whole class of problematic cases, 
and it would mean less junk for depsolvers to process, and less data to 
transfer over the wires.

I've a feeling there might be some corner cases in package splits, but 
haven't been able to come up with any real case, so it's probably just a 
false hunch.

> As for how many dependencies this would eliminate, running some quick queries
> [0] against the Fedora primary sqlite metadata database told me it'd be about
> 7.3% of all dependencies (9246/126066).  This is inaccurate (no versions in
> dependencies taken into account etc) but I think it should be the correct
> order of magnitude.
>
> Anyway, I'd guess it'd be fairly easy to implement the pruning in rpmbuild at
> build time - just first gather the Provides, then Requires, then drop all
> Requires that are satisfied by those Provides.
>
> Worth it?  Did I miss something?

7.3% savings (and even if that's slightly less in reality) would be well 
worth it, not to mention fixing the firefox etc cases IMO.

 	- Panu -


More information about the Rpm-maint mailing list