From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Q4ZZ7-0007TQ-Is for garchives@archives.gentoo.org; Tue, 29 Mar 2011 14:06:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C54721C127; Tue, 29 Mar 2011 14:06:23 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D4A611C034 for ; Tue, 29 Mar 2011 14:05:49 +0000 (UTC) Received: from portable.localnet (unknown [201.246.100.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 340681B41DE; Tue, 29 Mar 2011 14:05:49 +0000 (UTC) From: Alexis Ballier Organization: Gentoo To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav Date: Tue, 29 Mar 2011 11:05:43 -0300 User-Agent: KMail/1.13.6 (Linux/2.6.38; KDE/4.6.1; x86_64; ; ) Cc: =?utf-8?q?Tom=C3=A1=C5=A1_Chv=C3=A1tal?= References: <4D89FEC1.1030905@gentoo.org> <201103282312.49730.aballier@gentoo.org> <4D91D7B5.2060508@gentoo.org> In-Reply-To: <4D91D7B5.2060508@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201103291105.44232.aballier@gentoo.org> X-Archives-Salt: X-Archives-Hash: 88879be6dae074e1f2c03331071f8a5c On Tuesday, March 29, 2011 09:59:33 AM Tom=C3=A1=C5=A1 Chv=C3=A1tal 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=C3=A1=C5=A1 Chv=C3=A1tal 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. > >>>=20 > >>> So libav is stored in media-video/libav (look at it, try to find issu= es > >>> and stuff). > >>>=20 > >>> 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. > >>=20 > >> 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. > >=20 > > well, if you want to convert all the tree you'll need a versioned virtu= al > > because the >=3D deps are still needed > > (and the virtual should also have >=3D deps, not ~ nor =3D..* in order = not to > > force a downgrade because of an outdated virtual) > >=20 > > A. >=20 > 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 >=20 > If we would want versioned one we currently need 3 of them: >=20 > 0.5 including only ffmpeg >=3D 0.5 >=20 > 0.6 including libav or ffmpeg both >=3D 0.6 >=20 I would only add these 2 here > 0.7 including libav >=3D 0.7_pre or ffmpeg >=3D 0.6_p >=20 > So what do you think. there is no 0.7 for the moment, so we do not really care; we'll add new=20 virtual versions as the need comes; a quick look at your list shows 0.6 to = be=20 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 defaul= t=20 implementation a couple of days after the fork. libav is 'new' and shiny,=20 comes with better promises and everything, but why would they fork if they= =20 didnt ? :) Its already starting to be a mess with the versions differing... I can't wa= it=20 to see the next API break... I really wish one of the 2 forks will die rath= er=20 sooner than later.=20 A.