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(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.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.