Re: [Rpm-maint] Pruning self-dependencies?
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
Re: [Rpm-maint] Pruning self-dependencies?
On Mon, 2 Jul 2007, Ville Skyttä wrote: 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. Actually much of the benefit would be gained by just having createrepo drop self-requires out of the metadata. That would have an immediate benefit without requiring rebuilding the world. Of course you'd still be downloading the dependency bloat in the rpm's themselves but now that yum uses it's own depsolver doing this one the metadata level would already be beneficial. - Panu -___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Pruning self-dependencies?
Panu Matilainen wrote: On Mon, 2 Jul 2007, Ville Skyttä wrote: 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. Actually much of the benefit would be gained by just having createrepo drop self-requires out of the metadata. That would have an immediate benefit without requiring rebuilding the world. Of course you'd still be downloading the dependency bloat in the rpm's themselves but now that yum uses it's own depsolver doing this one the metadata level would already be beneficial. - Panu - Except of a potential C vs Python issue I see no reason why that should be the easier solution. Implementing it in rpmbuild would grant this benefit for everyone and not only yum users. Rpmbuild also has a much better chance to keep manually added requires. Florian ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Pruning self-dependencies?
On Fri, 6 Jul 2007, Florian Festi wrote: Panu Matilainen wrote: On Mon, 2 Jul 2007, Ville Skyttä wrote: 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. Actually much of the benefit would be gained by just having createrepo > drop self-requires out of the metadata. That would have an immediate benefit without requiring rebuilding the world. Of course you'd still be downloading the dependency bloat in the rpm's themselves but now that yum uses it's own depsolver doing this one the metadata level would already be beneficial. - Panu - Except of a potential C vs Python issue I see no reason why that should be the easier solution. Implementing it in rpmbuild would grant this benefit for everyone and not only yum users. Rpmbuild also has a much better chance to keep manually added requires. I didn't say it shouldn't be done in rpmbuild, obviously that's where it really belongs to. *Additionally* filtering them out on metadata generation would benefit existing users - apt and smart have done their own depsolving since day one and would benefit immediately, and yum since 3.2.x (for older versions it wouldn't matter much either way I think) - Panu -___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
