[Rpm-maint] Pruning self-dependencies?
mark.hatle at windriver.com
Mon Jul 9 16:00:12 UTC 2007
You are forgetting that you can query per file dependencies in modern
RPM produced packages. If you prune self-provided dependencies you lose
--filerequires and --fileprovides. Invaluable in my experience.
There just is no reason to prune self-fulfilled dependencies.
Panu Matilainen wrote:
> On Mon, 2 Jul 2007, Ville Skyttä wrote:
>> 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
>> 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
>> but what if the set of packages going to be installed anyway already
> 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
>>  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
More information about the Rpm-maint