ffmpeg for EL7

[Sérgio Basto]

Hi, 

Today I realized that ffmpeg-compat is not required by any package [1],
perhaps we may drop it (I still in review some packages that are lost
on migration for new infra (like subtitleripper)) .

Orion Poplawski, I'd like have an agreement on how put ffmpeg in epel7.
What you say ? may we have one ffmpeg ? , should we have multi ffmpegs
? etc. 

Thanks.

[1] 
dnf --disablerepo='*' --releasever=25 --enablerepo=rpmfusion-free --enablerepo=rpmfusion-nonfree repoquery
 --whatrequires ffmpeg-compat --available --refresh 
dnf repoquery --whatrequires ffmpeg-compat --available 




On Sáb, 2016-08-27 at 19:38 +0100, Sérgio Basto wrote:
> 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.c
> > > > > om
> > > > > > 
> > > > > > :
> > > > > > 
> > > > > > 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.20
> > > > > 10
> > > > > 0612svn.fc13.src.rpm
> > > > > Here are the ABI from ffmpeg upstream: http://ffmpeg.org/down
> > > > > lo
> > > > > 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.