Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Tue, 20 Jan 2015 22:43:52 +0100
Michał Górny <mgorny@g.o> wrote:

> Dnia 2015-01-20, o godz. 09:13:19
> Alexis Ballier <aballier@g.o> 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.