Please add sub-slots to ffmpeg ebuilds. libav ebuilds already use this feature of EAPI5, but it is not possible to fix virtual and reverse deps until media-video/ffmpeg is done. Next step would be fixing packages depending on virtual/ffmpeg.
subslot like 0/${PV} or 0/$branch are kinda useless for the virtual, no ? if you want something usefull then it should be something like the library major versions so that it can be uniform between libav and ffmpeg so that the virtual can use this too, but it seems libav ebuilds went the other way....
0/${PV} looks fine, isn't virtual bumped with new APIs?
(In reply to comment #2) > 0/${PV} looks fine, isn't virtual bumped with new APIs? but what's the plan then? how do you propagate ffmpeg subslots to the virtual? I may have missed something, subslots are rather new to me, I'm just making sure I understand well.
more specifically, let's consider the following scenario that, as of today, I see very likely: - ffmpeg-1.1.1 or later gets unmasked because its rev deps have been fixed - virtual/ffmpeg-9 remains masked since libav-9 is not ready in order not to force libav users to switch to ffmpeg - packages depending on virtual/ffmpeg subslots are fine, but people need to revdep-rebuild because they upgraded media-video/ffmpeg - some time after, virtual/ffmpeg gets unmasked with the subslots - people upgrading the virtual will rebuild everything again because the subslot virtual has changed, but they didn't have to because they did it when they upgraded media-video/ffmpeg
Bug 449094 requests sub-slot pass-through for virtuals. For now, I guess you have to bump the virtual version for each sub-slot (such as SLOT=0/${PV}), and have the virtual RDEPEND on a specific sub-slot (such as media-video/ffmpeg:0/${PV}).
(In reply to comment #5) > For now, I guess you have to bump the virtual version for each sub-slot > (such as SLOT=0/${PV}), and have the virtual RDEPEND on a specific sub-slot > (such as media-video/ffmpeg:0/${PV}). Not really an option considering the implementations are more and more desyncrhonized, we'd have to wait for passthrough I'm afraid.
I think is is probably obsolete now as we are moving to depending on libav of ffmpeg without relying in virtual but directly on the packages (switching with "libav" USE flag). The only issue is that there are still a lot of reverse deps using the old dep on the virtual... but that is another topic I think
