Re: ffmpeg for EL7
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(a)cora.nwra.com>:
> >
> > On 08/25/2016 02:30 PM, Nicolas Chauvet wrote:
> > >
> > > 2016-08-25 22:19 GMT+02:00 Orion Poplawski <orion(a)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.