ffmpeg for EL7

[Sérgio Basto]

On Sex, 2016-08-26 at 13:25 -0600, Orion Poplawski wrote:
> On 08/26/2016 01:35 AM, Nicolas Chauvet wrote:
> > 
> > 2016-08-26 0:23 GMT+02:00 Orion Poplawski <orion at cora.nwra.com>:
> > > 
> > > On 08/25/2016 02:30 PM, Nicolas Chauvet wrote:
> > > > 
> > > > 2016-08-25 22:19 GMT+02:00 Orion Poplawski <orion at cora.nwra.com
> > > > >:
> > > > > 
> > > > > On 08/25/2016 06:28 AM, Dominik 'Rathann' Mierzejewski wrote:
> > > > > > 
> > > > > > On Thursday, 25 August 2016 at 10:24, Ralf Corsepius wrote:
> > > > > > > 
> > > > > > > On 08/25/2016 10:01 AM, Nicolas Chauvet wrote:
> > > > > > [...]
> > > > > > > 
> > > > > > > > 
> > > > > > > > Specially as ffmpeg doesn't do symbol version, if one
> > > > > > > > process has
> > > > > > > > dependencies using both version, it will crash.
> > > > > > > AFAIU, as long as these packages are properly linked (and
> > > > > > > not libraries
> > > > > > > not being dlopened), package deps on SONAMEs would
> > > > > > > conflict and thus
> > > > > > > prevent such problems.
> > > > > > The point is that not all SONAMEs change with each FFmpeg
> > > > > > version bump,
> > > > > > so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have
> > > > > > mostly the same
> > > > > > SONAMEs.
> > > > > Here is an attempt at ffmpeg2.8 and ffmpeg3.0.  This relies
> > > > > on different
> > > > I've strictly no question about how not to make conflict
> > > > between
> > > > theses, so I'm not even looking at your spec since I don't
> > > > think they
> > > > will bring any value to the "discution".
> > > > Please have a look at ffmpeg-compat for not conflicting with
> > > > -devel
> > > > Also please have a look this for not conflicting with ffmpeg
> > > > version
> > > > of the same ABI:
> > > > http://rpms.kwizart.net/fedora/16/SRPMS/ffmpeg4vlc-0.6-0.4.2010
> > > > 0612svn.fc13.src.rpm
> > > > Here are the ABI from ffmpeg upstream: http://ffmpeg.org/downlo
> > > > ad.html#releases
> > > Well, I'll give you the courtesy of looking at your specs, even
> > > if you won't
> > > do the same for me.
> > You are still in the "How not to make conflicts" question whereas
> > this
> > question is out of interest over "which version to choose for a
> > general usage."
> I'm trying to be concerned with the question - "What happens when the
> version
> needed for general usage changes?  How can that be done in the least
> impactful
> way by planning for that transition now?"
> 
> > 
> > You are still in the false premise that you can have any versions
> > as
> > soon as they do not conflict for general usage and let packagers
> > choose theirs.
> Why is this a false premise?  It seems perfectly reasonable to have
> ffmpeg2.8
> to start, and add a ffmpeg3.X when there is a critical mass of other
> software
> that requires it.  And then keep sliding this forward as necessary,
> and then
> when necessary dropping the old ffmpeg2.8, etc. when they are
> unsupportable.
> We're talking 8 more years for EL7 to be around.
> 

The 8 years argument is good but one point is need keep it simple. From
what I see, end use shouldn't have choices, we build applications
against the main ffpmeg , we already have ffmpeg-compat, if in 4 years
we need update ffmpeg, we update the main ffmpeg , if something still
need old ffmpeg we can make one second ffmpeg-compat-2.8 or ffmpeg-3
(if want innovate) but when we need that ? in 4 years, now we need just
one main ffmpeg .

Don't like the idea have the possibility of install lots of versions of
ffmpeg , end user just need one and shouldn't worry about what version
is, your solution is more complicated, may give much more work and I
don't see great benefits.


> > 
> > You have also ignored several of my earlier comments, so I wouldn't
> > say courtesy is on your side here.
> I certainly didn't do so intentionally.  I've just replied to an
> earlier
> email, perhaps that helps.
> 
> > 
> > This discussion has gone wrong, so I'm dropping here.
> Deep breath, start again.
> 
-- 
Sérgio M. B.