On Tue, 20 Jan 2015 22:43:52 +0100 Michał Górny <mgo...@gentoo.org> wrote:
> Dnia 2015-01-20, o godz. 09:13:19 > Alexis Ballier <aball...@gentoo.org> napisał(a): > > > > 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... > > It's no better than it is now. I don't see any obvious solution, > except maybe for fake flags that would shout loudly at users, like > USE=libav with matching pkg_pretend() telling to change the global > flag. As I see it, this problem has no solution unless we're going to > make the two co-installable. There is indeed no solution I can think of but it is a bit worse than what it is now at first: People that wanted to chose put their implementation in world and were done. With this solution, such people will have to adapt their useflags in make.conf. Don't get me wrong: I'm all for changing it as you suggest (or remi suggests), I'm just saying users might have a hard time finding out what those portage blockers mean and how to fix it. In the long term your proposal is a better solution but the first time will be painful IMHO. > > - 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. > > It will *at least* make those issues explicit and visible to repoman. > Rather than discovered via users hitting impossible dep trees. They're usually not impossible, but my point was rather: Is this something everyone wants ? > > - What to do with packages like mplayer that haven't been building > > against libav for a year or so ? > > I don't know. pkg_pretend() like suggested above? Me neither. pkg_pretend will be too intrusive into packages I think (and there are quite a few). I remember something that enabled useflags based on if you had a given package installed. /me runs > > > 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. > > Following a specification is not a bug. I could argue here a lot > but... just implement it. And return to us when you do. We had an > item for this for EAPI 6, and it was removed because nobody > volunteered to implement it. In fact, nobody even were able to fully > specify what it should do... but if you want to discuss that, please > start a new thread, possibly at the -pms list. Above is a simple algorithm that works in all cases. What you're asking me to do is "go beg pms list to allow something they don't want because the subslot/:= spec was poorly written and thought of". I already gave you the solution, don't count on me for the administrative work :=) (NB: everytime I tried to improve/fix something in pms I failed miserably, so that I have no other choice but giving up on this, check bgo) Moreover, when I bumped ffmpeg subslot, portage did rebuild all those packages with || ( := := ) deps properly for me. So, you'll have to be a bit more specific on what goes wrong than 'broken || ( libav:= ffmpeg:= )'... Alexis.
