1 |
On Wednesday, March 23, 2011 11:23:48 AM Samuli Suominen wrote: |
2 |
> On 03/23/2011 04:08 PM, Tomáš Chvátal wrote: |
3 |
> > Hi guys, |
4 |
> > As there is new ffmpeg fork that is a bit alive we should provide it as |
5 |
> > alternative to current media-video/ffmpeg. |
6 |
> > |
7 |
> > So libav is stored in media-video/libav (look at it, try to find issues |
8 |
> > and stuff). |
9 |
> > |
10 |
> > Virtual package is virtual/ffmpeg where now i implemented it to have |
11 |
> > versioned dependencies. |
12 |
> > So there is virtual/ffmpeg-0.6 virtual/ffmpeg-9999 where the apps can |
13 |
> > decide what they need. |
14 |
> > Samuli pointed out that we do not slot ffmpeg nor support versioned deps |
15 |
> > and always demand everything to be working with latest. If you have |
16 |
> > strong opinion on that one please express it here so the virtual gets |
17 |
> > redesigned to just simple virtual/ffmpeg-0.1 without any version stated |
18 |
> > in it. I myself like the chance to express the version explicitly. |
19 |
> > Virtual itself provide access to all useflags currently used in eapi2 |
20 |
> > deps. More can be added when required. |
21 |
> |
22 |
> With the same logic we have always pulled in from master, instead of |
23 |
> release trees (such as 0.5.x, 0.6.x). |
24 |
> It's not legal to set versioned deps forcing downgrade on same |
25 |
> stabilization level (stable, or ~arch) as that will just cause |
26 |
> dependency conflict. Applies to any package. |
27 |
> So just punt the just committed virtuals and just leave |
28 |
> virtual/ffmpeg-0.ebuild. Anything that doesn't work with latest and is |
29 |
> not fixed in reasonable time, gets lastrited like before. |
30 |
|
31 |
|
32 |
well, if you want to convert all the tree you'll need a versioned virtual |
33 |
because the >= deps are still needed |
34 |
(and the virtual should also have >= deps, not ~ nor =..* in order not to |
35 |
force a downgrade because of an outdated virtual) |
36 |
|
37 |
A. |