Taskotron misses dropped subpackages

[Michael Schwendt]

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.