Heads up! Broken deps in Upgrade from 12 to 13

[Braden McDaniel]

On Sun, 2010-02-21 at 19:43 +0100, Michael Schwendt wrote: 
> On Sat, 20 Feb 2010 20:46:14 -0500, Braden wrote:
> 
> > >    Upgrade from  12+updates  to  13+updates+testing
> 
> > > broken deps look like below. While several may be due to dead packages
> > > that have been removed in 13, some are likely due to violated upgrade
> > > paths and bad/missing Obsoletes for old subpackages.
> > > 
> > > [...]
> > > 
> > > Summary of broken packages (by src.rpm name):
> > 
> > [snip]
> > 
> > >     openvrml
> > 
> > [snip]
> > 
> > > openvrml-0.18.3-5.fc12.i686  requires  libboost_thread-mt.so.5
> > >     openvrml-0.18.3-5.fc12.i686  requires  libboost_filesystem-mt.so.5
> > 
> > This doesn't look to me like F12 updates are being factored in properly.
> 
> Not true.

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

> 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.

So what exactly is the upgrade path that's being tested and failing
here?

> 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.  It was replaced by libopenvrml-devel;
libopenvrml-devel already Obsoletes: openvrml-devel.

These changes that are in F13 are also in F12 updates.

> so openvrml is no longer chosen for the
> multilib repo compose. Some packagers fix that with "self-obsoletes".
> 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.

-- 
Braden McDaniel <braden at endoframe.com>