Mythtv is preventing the update of libvpx to 1.5.0. Not being able to upgrade to 1.5.0 is preventing the latest chromium update chromium-54.0.2840.59. Reading through the bug reports, it looks like mythtv (currently masked) 0.28 will work with the updated libvpx. At the moment, stable mythtv, libvpx and chromium will not compile together. Reproducible: Always Steps to Reproduce: 1.emerge -uDNav world 2. 3. Actual Results: Total: 6 packages (6 upgrades), Size of downloads: 563,912 KiB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: media-libs/libvpx:0 (media-libs/libvpx-1.5.0:0/3::gentoo, ebuild scheduled for merge) pulled in by media-libs/libvpx:=[svc] required by (www-client/chromium-54.0.2840.59:0/0::gentoo, ebuild scheduled for merge) ^^^ (media-libs/libvpx-1.4.0:0/2::gentoo, installed) pulled in by >=media-libs/libvpx-1.3.0:0/2=[abi_x86_32(-),abi_x86_64(-)] required by (media-plugins/gst-plugins-vpx-1.8.3:1.0/1.0::gentoo, installed) ^^^^^ <media-libs/libvpx-1.5.0:= required by (media-tv/mythtv-0.27.6_p20160318:0/0.27.6_p20160318::gentoo, ebuild scheduled for merge) ^ ^^^^^ ^ Expected Results: updated happy system.
Please note that this is somewhat urgent as the blocked chromium update causes security fixes being missed. Maybe libvpx needs slotting as it seems the library API changes in about every release.
I don't have an environment to test MythTV currently but you can try building MythTV against a newer version and report back. With that information that would help me do any changes necessary. If that doesn't work however the only path forward would be to have the maintainers of libvpx SLOT the package. @media-video/chromium: Have you considered SLOTing this package since it has ABI tweaks constantly?
Actually, you don't have to bother testing against a newer version since the versions aren't compatible. They do break API/ABI between versions and need to be SLOTed and not sub-SLOTed. @media-video/chromium: Can you make this happen? https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dabd9842b5f0cecb28601ff0e2ba793afbde85e5 https://bugs.gentoo.org/show_bug.cgi?id=565628
(In reply to Doug Goldstein from comment #2) > I don't have an environment to test MythTV currently but you can try > building MythTV against a newer version and report back. With that > information that would help me do any changes necessary. If that doesn't > work however the only path forward would be to have the maintainers of > libvpx SLOT the package. > > @media-video/chromium: Have you considered SLOTing this package since it has > ABI tweaks constantly? The usual way of dealing with this is subslot, := deps like it is the case, and fixing reverse deps. Without upstream properly maintaining older versions, SLOTing is just postponing the inevitable: library will bitrot and reverse deps will still be using the bitrotted version. Also, SLOTing can only be useful to binary packages without heavy patching: when libraries are slotted, they just install the '.so.X', not the headers nor the .so/.pc etc.
(In reply to Alexis Ballier from comment #4) > (In reply to Doug Goldstein from comment #2) > > I don't have an environment to test MythTV currently but you can try > > building MythTV against a newer version and report back. With that > > information that would help me do any changes necessary. If that doesn't > > work however the only path forward would be to have the maintainers of > > libvpx SLOT the package. > > > > @media-video/chromium: Have you considered SLOTing this package since it has > > ABI tweaks constantly? > > The usual way of dealing with this is subslot, := deps like it is the case, > and fixing reverse deps. Without upstream properly maintaining older > versions, SLOTing is just postponing the inevitable: library will bitrot and > reverse deps will still be using the bitrotted version. Surely you don't mean that you subslot packages that have incompatible APIs. Because that's what the issue is here. Its an API and ABI break. So simply recompiling does not solve the issue.
(In reply to Doug Goldstein from comment #5) > (In reply to Alexis Ballier from comment #4) > > (In reply to Doug Goldstein from comment #2) > > > I don't have an environment to test MythTV currently but you can try > > > building MythTV against a newer version and report back. With that > > > information that would help me do any changes necessary. If that doesn't > > > work however the only path forward would be to have the maintainers of > > > libvpx SLOT the package. > > > > > > @media-video/chromium: Have you considered SLOTing this package since it has > > > ABI tweaks constantly? > > > > The usual way of dealing with this is subslot, := deps like it is the case, > > and fixing reverse deps. Without upstream properly maintaining older > > versions, SLOTing is just postponing the inevitable: library will bitrot and > > reverse deps will still be using the bitrotted version. > > Surely you don't mean that you subslot packages that have incompatible APIs. > Because that's what the issue is here. Its an API and ABI break. So simply > recompiling does not solve the issue. That's why revdeps need to be fixed. If upstream doesn't implement a proper way of slotting it (different header locations, different .pc files, different libnames, etc.) and doesn't maintain old releases, sloting is definitely a no-go: Changing the first would require to use non-standard .pc names and non-standard libnames breaking all the existing checks in the revdeps; maintaining downstream an old unmaintained release isn't a terrible idea either. If they don't support this and break API in a way that makes distributors work impossible then maybe they should be notified about this ?
*** Bug 605136 has been marked as a duplicate of this bug. ***
