On Wed, 21 Jan 2015 11:48:55 -0700, Tim Flink wrote: > > Taskotron doesn't notice if subpackages have been dropped and cause > > unresolvable dependencies because they are not obsoleted anywhere. > > This isn't so much something that taskotron's checks missed as it's > something we're not even checking for. > > > Examples: jogl2-javadoc, miglayout-examples, > > glusterfs-regression-tests rubygem-json-doc, rubygem-rake-doc, and > > more > > I don't really see the unresolvable deps here. When I run all of your > examples though 'repoquery --whatrequires', they all return nothing > which implies that nothing requires them and there are no broken dep > chains as a result of those dropped subpackages (which I suspect is > not what you'd like to see checked). The problem is a different one: A dropped subpackage, if installed already, may depend on other packages that are installed. If there's a strict dependency, e.g. on a specific %version-%release of something, an upgrade would be impossible. Unless the dropped subpackage were obsoleted properly. > > Yum is broken in the same way. And by design. When installing a > > discontinued subpackage, it happily installs any "old" packages it > > still finds in the repos to satisfy dependencies, but it cannot > > upgrade the installation afterwards because of unsatisfied deps. > > If I'm understanding correctly, your concern is about what happens at > upgrade time when those improperly obsoleted subpackages are still > installed on a system. Since they don't exist in the repos anymore, > upgrading them is impossible. Upgrading the requirements is what leads to unresolvable deps. One can only upgrade, if one removes the dropped subpackage manually. > While I'm certainly not arguing that this isn't something that we > should check for, it's not really covered by any existing checks. I'm > certainly game for adding a new check for this but unless it's a bigger > problem than I think it is, I'd rather put it off until after we've > been able to land the new features we're currently working on. That's up to you, of course. Once you understand _the problem_, your point of view may change. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
