Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav

[Alexis Ballier]

On Tuesday, March 29, 2011 09:59:33 AM Tomáš Chvátal wrote:
> Dne 29.3.2011 04:12, Alexis Ballier napsal(a):
> > On Wednesday, March 23, 2011 11:23:48 AM Samuli Suominen wrote:
> >> On 03/23/2011 04:08 PM, Tomáš Chvátal wrote:
> >>> Hi guys,
> >>> As there is new ffmpeg fork that is a bit alive we should provide it as
> >>> alternative to current media-video/ffmpeg.
> >>>
> >>> So libav is stored in media-video/libav (look at it, try to find issues
> >>> and stuff).
> >>>
> >>> Virtual package is virtual/ffmpeg where now i implemented it to have
> >>> versioned dependencies.
> >>> So there is virtual/ffmpeg-0.6 virtual/ffmpeg-9999 where the apps can
> >>> decide what they need.
> >>> Samuli pointed out that we do not slot ffmpeg nor support versioned
> >>> deps and always demand everything to be working with latest. If you
> >>> have strong opinion on that one please express it here so the virtual
> >>> gets redesigned to just simple virtual/ffmpeg-0.1 without any version
> >>> stated in it. I myself like the chance to express the version
> >>> explicitly. Virtual itself provide access to all useflags currently
> >>> used in eapi2 deps. More can be added when required.
> >>
> >> With the same logic we have always pulled in from master, instead of
> >> release trees (such as 0.5.x, 0.6.x).
> >> It's not legal to set versioned deps forcing downgrade on same
> >> stabilization level (stable, or ~arch) as that will just cause
> >> dependency conflict. Applies to any package.
> >> So just punt the just committed virtuals and just leave
> >> virtual/ffmpeg-0.ebuild.  Anything that doesn't work with latest and is
> >> not fixed in reasonable time, gets lastrited like before.
> >
> > well, if you want to convert all the tree you'll need a versioned virtual
> > because the >= deps are still needed
> > (and the virtual should also have >= deps, not ~ nor =..* in order not to
> > force a downgrade because of an outdated virtual)
> >
> > A.
>
> Well the virtuals can be versioned as i said previously, altho others
> convinced me that unversioned are desirable.


you were right to version them at the beginning for the above reasons


>
> If we would want versioned one we currently need 3 of them:
>
> 0.5 including only ffmpeg >= 0.5
>
> 0.6 including libav or ffmpeg both >= 0.6
>

I would only add these 2 here

> 0.7 including libav >= 0.7_pre or ffmpeg >= 0.6_p
>
> So what do you think.

there is no 0.7 for the moment, so we do not really care; we'll add new 
virtual versions as the need comes; a quick look at your list shows 0.6 to be 
the highest required version by some packages.

> For the || dependencies order it should be lazy evaluated for 2 years now.

Still, you're making the jump rather quickly by having a fork as the default 
implementation a couple of days after the fork. libav is 'new' and shiny, 
comes with better promises and everything, but why would they fork if they 
didnt ? :)

Its already starting to be a mess with the versions differing... I can't wait 
to see the next API break... I really wish one of the 2 forks will die rather 
sooner than later. 

A.