On Mon, 19 Jan 2015 20:31:45 +0100 Michał Górny <[email protected]> wrote:
> Hello, > > As we've discussed multiple times, the following kind of dependencies > is completely broken and can't work: > > || ( media-libs/libav:= media-libs/ffmpeg:= ) See end of the email. > For this reason, I would like to employ the solution used by Exherbo. > More specifically, use: > > libav? ( media-libs/libav:= ) > !libav? ( media-libs/ffmpeg:= ) > > This has two advantages: > > 1. gives users more explicit control over whether they want to use > libav or ffmpeg. Since the two have mutual blockers, right now random > packages could have tried to force you to switch from one to the > other. However, most often Portage would just give you terribly > unreadable blockers. This sounds good to me; there are a few things to consider though: - Whatever default useflag is enabled, people will have "terribly unreadable blockers" if they use the other implementation. It is even worse if you want to follow upstreams in their preferred implementation: some want libav, others ffmpeg... - This is hidden by the proposal but it enforces that a package has equal visibility of both implementations (while the || requires only one); libav tends to have a faster code cleaning rate and thus a slower unmasking rate in gentoo. I agree with that requirement but this might end-up being unpractical since this means packages keywording and stabilization will have the slowest pace: mpv has been masked for 4 months and counting for this reason. - What to do with packages like mplayer that haven't been building against libav for a year or so ? - ffmpeg dep is media-video/ffmpeg:0= (not media-libs but more importantly the :0=) - It is a good opportunity to kill virtual/ffmpeg and at the same time workaround a subslot and := deps limitation with virtuals. > 2. Subslots work correctly. Rebuilds are forced when the chosen > library is upgraded. Moreover, USE flag change causes a rebuild when > user decides to change the ffmpeg provider. No offense, but this argument is complete crap. You should rather fix portage bugs than propose to introduce tree-wide changes to hide them... More precisely: || ( a:= b c:= d ) is perfectly defined (in the "what it means" sense, not in PMS sense). When the package is built, if 'a' is satisfied then a (and its subslot) is added to the subslot list of the package; ditto for c. You end up with a list of subslot deps, that you can store in vdb or whatever, and use that to decide when to rebuild the package. Alexis.
