Re: [Rpm-maint] Pruning self-dependencies?
On Mon, 9 Jul 2007, Mark Hatle wrote: 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. Heh, I'd never noticed rpm *had* such options... I can see how those are useful for some purposes such as digging out where exactly some dependency bloat comes from. Pruning self-requires wouldn't affect the utility of that much I think. This actually makes me think it'd be nice if there was a tool for running the internal dependency generator on arbitrary files (outside rpmbuild) so you could look at any file/filelist and see how rpm classifies them and what dependencies it'll produce. There just is no reason to prune self-fulfilled dependencies. Saving memory and bandwith is no reason? Out of curiosity, what exactly do you use those --filerequire and --fileprovide options for? Like said, I can see some purposes where they can be useful but it's not like they're required for average every day operation :) - 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: 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
Re: [Rpm-maint] Pruning self-dependencies?
On Monday 02 July 2007, Adam Jackson wrote: On Mon, 2007-07-02 at 21:50 +0300, 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. Of those, how many are used as Requires: from other packages? I don't know, but... why? I'm not sure how that's related to pruning self-Requires; I can see how it could relate to reducing the number of Provides but that's a different beast, and a much tougher one. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Pruning self-dependencies?
Ville Skyttä ([EMAIL PROTECTED]) said: Worth it? Did I miss something? Notably, this fixes cases where an app has its own copy of a particular library set (with RPATH) and still ends up pulling in other implementations of that ABI. Such as the mozilla/firefox stack. Bill ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
