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