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.
