Heads up! Broken deps in Upgrade from 12 to 13

[Michael Schwendt]

On Sun, 21 Feb 2010 15:21:22 -0500, Braden wrote:

> Then I still don't understand this.  openvrml-devel went away between
> F12 and F12-updates.

Then you've broken F12, too, ... but it doesn't result in broken deps yet
because the SONAME deps of the builds haven't changed. Unlike F13.
As soon as you would have to rebuild openvrml for any ABI change in
some of its deps, the dep breakage in F12 would turn up, too.

> > Btw, the report explicitly refers to "fedora-updates-12-i386"
> > and "fedora-updates-12-x86_64" in two of its section titles and lists
> > many packages found in those repos.
> > 
> > > openvrml-0.18.3-10 is currently in F12 updates.
> > 
> > Doesn't matter, because your quote is truncated. The two .i686 lines
> > you've quoted are about openvrml.i686 in the fedora-12-x86_64 repo (!).
> 
> Yes, I missed that and consequently left some important information out
> of my quote.  But I'm not clear on why it doesn't matter that
> openvrml-0.18.3-10 is currently in F12 updates.

That package in F12 updates doesn't replace
openvrml-0.18.3-5.fc12.i686 in the Fedora 12 x86_64 repo.
 
> So what exactly is the upgrade path that's being tested and failing
> here?

See initial message:  F-12 + updates  -->  F-13 + updates-testing

> > It's multilib breakage. Some time between F12 updates and F13 you've
> > killed openvrml-devel,
> 
> That's not quite accurate.  openvrml-devel was killed between F12 (not
> updated) and F13.

Again, that doesn't matter. I don't have the time to browse all
the packages in koji. I see that openvrml-0.18.3-5.fc12 in stock F-12
still shipped openvrml-devel. Some time later, that subpkg was killed.
When exactly that was, is unimportant.

> It was replaced by libopenvrml-devel;
> libopenvrml-devel already Obsoletes: openvrml-devel.

But results in a different multiarch compose. libopenvrml-devel => libopenvrml
instead of openvrml-devel => openvrml

> > In the "openvrml" package:
> > 
> >   Obsoletes: openvrml < %{version}-%{release}
> > 
> > That way, openvrml.x86_64 would replace an old/obsolete openvrml.i686,
> > if installed.
> 
> I can do this; but I don't understand why the existence of
> libopenvrml-devel and its "Obsoletes: openvrml-devel" aren't sufficient.

See above.  Part of the current multiarch repo compose strategy is to pull
in all -devel packages and their dependency chains.  Initially, you've had
openvrml-devel.i686 add openvrml.i686 in the F-12 x86_64 repo. Then you've
modified packages _after_ release of F12. The old openvrml.i686 is still
in the x86_64 repo and might be installed on some users' machines, too.
Nothing upgrades or obsoletes it. Hence self-obsoletes are the only way
so far to avoid such an issue.