[Rpm-maint] Pruning self-dependencies?

[Mark Hatle]

You are forgetting that you can query per file dependencies in modern
RPM produced packages.  If you prune self-provided dependencies you lose
this information.

--filerequires and --fileprovides.  Invaluable in my experience.

There just is no reason to prune self-fulfilled dependencies.

--Mark

Panu Matilainen wrote:
> 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 -
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Rpm-maint mailing list
> Rpm-maint at lists.rpm.org
> https://lists.rpm.org/mailman/listinfo/rpm-maint