[gentoo-dev] Unmasking >=media-video/ffmpeg-4.0

[Craig Andrews]

I think it's time to remove the mask on >=media-video/ffmpeg-4.0

ffmpeg 4 is in many distros (including Debian, Arch) and FreeBSD.
Upstreams are starting to require it, too. For example, Kodi 18 and
media-plugins/gst-plugins-libav-16 will require it.

The blocker issue https://bugs.gentoo.org/653678 has only 5 blockers
against it right now:
* 654628 has a pull request out to fix it:
https://github.com/gentoo/gentoo/pull/10341
* 655170 is for a package that (IMHO) should be last-rited:
media-libs/mediastreamer
* 666166 is for a package that (IMHO) should be last-rited:
media-plugins/vdr-image
* 655442 and 658128 are for media-video/mplayer and fixed upstream,
requiring a new snapshot release

What do we say? Can we set a date when the hard mask will be removed?

Thanks,
~Craig

[Alexis Ballier]

On Mon, 05 Nov 2018 20:38:58 -0500

Post by Craig Andrews
I think it's time to remove the mask on >=media-video/ffmpeg-4.0
ffmpeg 4 is in many distros (including Debian, Arch) and FreeBSD.
Upstreams are starting to require it, too. For example, Kodi 18 and
media-plugins/gst-plugins-libav-16 will require it.
The blocker issue https://bugs.gentoo.org/653678 has only 5 blockers
https://github.com/gentoo/gentoo/pull/10341
media-libs/mediastreamer
media-plugins/vdr-image
* 655442 and 658128 are for media-video/mplayer and fixed upstream,
requiring a new snapshot release
What do we say? Can we set a date when the hard mask will be removed?

I think 6 months qualifies for ETIMEOUT, so go ahead and unmask it :)

merge the github PR; I'll take care of mplayer

[Mart Raudsepp]

Post by Alexis Ballier
On Mon, 05 Nov 2018 20:38:58 -0500

Post by Craig Andrews
I think it's time to remove the mask on >=media-video/ffmpeg-4.0
ffmpeg 4 is in many distros (including Debian, Arch) and FreeBSD.
Upstreams are starting to require it, too. For example, Kodi 18 and
media-plugins/gst-plugins-libav-16 will require it.
The blocker issue https://bugs.gentoo.org/653678 has only 5
blockers
https://github.com/gentoo/gentoo/pull/10341
media-libs/mediastreamer
media-plugins/vdr-image
* 655442 and 658128 are for media-video/mplayer and fixed
upstream,
requiring a new snapshot release
What do we say? Can we set a date when the hard mask will be
removed?

I think 6 months qualifies for ETIMEOUT, so go ahead and unmask it :)
merge the github PR; I'll take care of mplayer

I'm sorry, but what?
PR was filed yesterday, what 6 months are you talking about here?
Please respect your fellow developers. We have other commitments and
priorities and can't zero-day review a PR.

It is not GStreamer fault that ffmpeg breaks API and ABI without
parallel installability, much less so the distro maintainers of it.
If you/upstream don't make it parallel installable, then this is what
you get.


Mart

[Alexis Ballier]

On Tue, 06 Nov 2018 17:08:22 +0200

Post by Mart Raudsepp

Post by Alexis Ballier
On Mon, 05 Nov 2018 20:38:58 -0500

Post by Craig Andrews
I think it's time to remove the mask on >=media-video/ffmpeg-4.0
ffmpeg 4 is in many distros (including Debian, Arch) and FreeBSD.
Upstreams are starting to require it, too. For example, Kodi 18 and
media-plugins/gst-plugins-libav-16 will require it.
The blocker issue https://bugs.gentoo.org/653678 has only 5 blockers
https://github.com/gentoo/gentoo/pull/10341
media-libs/mediastreamer
media-plugins/vdr-image
* 655442 and 658128 are for media-video/mplayer and fixed
upstream,
requiring a new snapshot release
What do we say? Can we set a date when the hard mask will be removed?

I think 6 months qualifies for ETIMEOUT, so go ahead and unmask it :)
merge the github PR; I'll take care of mplayer

I'm sorry, but what?
PR was filed yesterday, what 6 months are you talking about here?
Please respect your fellow developers. We have other commitments and
priorities and can't zero-day review a PR.

Oh, sorry, I did not even check what the PR was about nor its
uptime. It should definitely read as "get the PR merged" then.

6 months is when bugs started to be filled which by most standards a
package not fixed within that time can be considered dead/unmaintained.
I usually take no response for a couple of months as a green light to
do it myself.

Post by Mart Raudsepp
It is not GStreamer fault that ffmpeg breaks API and ABI without
parallel installability, much less so the distro maintainers of it.
If you/upstream don't make it parallel installable, then this is what
you get.

Are you, seriously, suggesting this is the solution to all problems
here ?

Bests,

Alexis.

[Rich Freeman]

Post by Alexis Ballier
On Tue, 06 Nov 2018 17:08:22 +0200

Post by Mart Raudsepp
It is not GStreamer fault that ffmpeg breaks API and ABI without
parallel installability, much less so the distro maintainers of it.
If you/upstream don't make it parallel installable, then this is what
you get.

Are you, seriously, suggesting this is the solution to all problems
here ?

It isn't the only solution, but it is one sane upgrade path. You
can't expect everybody to update their software overnight when the API
changes. That means you have to support the old API for a while when
you introduce a new one, otherwise you end up with some software that
doesn't work with the old version, and some software that doesn't work
with the new version.

Inevitably you get some program that is either simple or has a ton of
manpower that refactors to the new API very quickly and abandons
versions using the old API, and then you have some other program that
is very complex or low-manpower that takes forever to adopt it.

Now, parallel installation isn't the only way to accomplish this
inter-compatibility, but it is one way.

It seems like everybody is determined to go down the
appimage/container path and just make dll-hell the new standard for
linux. When every program gets bundled with its on zlib you don't
have to worry about compatibility. Now you just get to update all 47
copies of it when a vulnerability turns up, and hope that the fix is
backported to all 13 versions you're implicitly using.

[Alexis Ballier]

On Tue, 6 Nov 2018 11:09:17 -0500

Post by Rich Freeman

Post by Alexis Ballier
On Tue, 06 Nov 2018 17:08:22 +0200

Post by Mart Raudsepp
It is not GStreamer fault that ffmpeg breaks API and ABI without
parallel installability, much less so the distro maintainers of
it. If you/upstream don't make it parallel installable, then this
is what you get.

Are you, seriously, suggesting this is the solution to all problems
here ?

It isn't the only solution, but it is one sane upgrade path. You
can't expect everybody to update their software overnight when the API
changes. That means you have to support the old API for a while when
you introduce a new one, otherwise you end up with some software that
doesn't work with the old version, and some software that doesn't work
with the new version.

These days, only symbols/constants that have been deprecated (and
marked as such) for a couple of releases are removed. This means people
see warnings for more than one year before seeing them gone for good.
The problem here is not "overnight changes" but rather consumers not
paying attention to those warnings, or worse, nobody ever seeing those
because it's unmaintained.


[...]

Alexis.

[Ian Stakenvicius]

Post by Alexis Ballier
On Tue, 6 Nov 2018 11:09:17 -0500

Post by Rich Freeman

Post by Alexis Ballier
On Tue, 06 Nov 2018 17:08:22 +0200

Post by Mart Raudsepp
It is not GStreamer fault that ffmpeg breaks API and ABI without
parallel installability, much less so the distro maintainers of
it. If you/upstream don't make it parallel installable, then this
is what you get.

Are you, seriously, suggesting this is the solution to all problems
here ?

It isn't the only solution, but it is one sane upgrade path. You
can't expect everybody to update their software overnight when the API
changes. That means you have to support the old API for a while when
you introduce a new one, otherwise you end up with some software that
doesn't work with the old version, and some software that doesn't work
with the new version.

These days, only symbols/constants that have been deprecated (and
marked as such) for a couple of releases are removed. This means people
see warnings for more than one year before seeing them gone for good.
The problem here is not "overnight changes" but rather consumers not
paying attention to those warnings, or worse, nobody ever seeing those
because it's unmaintained.

But we aren't upstream most of the time, and if upstreams are pegging
their ffmpeg to a single version they don't bother to try the newer
one to find out the errors. Take Kodi, v17.x is pegged to no newer
than ffmpeg-3.3.x as I recall, and has been blocking even v3.4's
installation for the year'ish it's been in the gentoo repo.

So this "people see warnings" thing, it really doesn't apply, unless
you (A) have the desire and resources to build and maintain a patch
for upstream, and (B) have an upstream with the desire and resources
to support more than the one version of ffmpeg for a given release
set. Both, IMO, are in very short supply.

[Alexis Ballier]

On Wed, 7 Nov 2018 09:57:36 -0500

Post by Ian Stakenvicius

Post by Alexis Ballier
On Tue, 6 Nov 2018 11:09:17 -0500

On Tue, Nov 6, 2018 at 10:57 AM Alexis Ballier

Post by Alexis Ballier
On Tue, 06 Nov 2018 17:08:22 +0200

Post by Mart Raudsepp
It is not GStreamer fault that ffmpeg breaks API and ABI without
parallel installability, much less so the distro maintainers of
it. If you/upstream don't make it parallel installable, then this
is what you get.

Are you, seriously, suggesting this is the solution to all
problems here ?

It isn't the only solution, but it is one sane upgrade path. You
can't expect everybody to update their software overnight when the
API changes. That means you have to support the old API for a
while when you introduce a new one, otherwise you end up with some
software that doesn't work with the old version, and some software
that doesn't work with the new version.

These days, only symbols/constants that have been deprecated (and
marked as such) for a couple of releases are removed. This means
people see warnings for more than one year before seeing them gone
for good. The problem here is not "overnight changes" but rather
consumers not paying attention to those warnings, or worse, nobody
ever seeing those because it's unmaintained.

But we aren't upstream most of the time, and if upstreams are pegging
their ffmpeg to a single version they don't bother to try the newer
one to find out the errors. Take Kodi, v17.x is pegged to no newer
than ffmpeg-3.3.x as I recall, and has been blocking even v3.4's
installation for the year'ish it's been in the gentoo repo.
So this "people see warnings" thing, it really doesn't apply, unless
you (A) have the desire and resources to build and maintain a patch
for upstream, and (B) have an upstream with the desire and resources
to support more than the one version of ffmpeg for a given release
set. Both, IMO, are in very short supply.

Believe me, it's far easier to do this than maintaining several slotted
versions. See the amount of work done for e.g. gtk, qt, wxwidgets, etc.
and I'm not even counting backporting security fixes nor patching tens
of packages to "use the proper slot".

Note that the (B) desire is usually mostly killed by people claiming
multiple versions should be supported without any idea of the
implications this has. Fortunately, there's only very few upstreams
left that consider ffmpeg so special that they want to bundle or force
an old buggy and vulnerable version.

[Craig Andrews]

Post by Alexis Ballier
On Mon, 05 Nov 2018 20:38:58 -0500

Post by Craig Andrews
I think it's time to remove the mask on >=media-video/ffmpeg-4.0
ffmpeg 4 is in many distros (including Debian, Arch) and FreeBSD.
Upstreams are starting to require it, too. For example, Kodi 18 and
media-plugins/gst-plugins-libav-16 will require it.
The blocker issue https://bugs.gentoo.org/653678 has only 5 blockers
https://github.com/gentoo/gentoo/pull/10341
media-libs/mediastreamer
media-plugins/vdr-image
* 655442 and 658128 are for media-video/mplayer and fixed upstream,
requiring a new snapshot release
What do we say? Can we set a date when the hard mask will be removed?

I think 6 months qualifies for ETIMEOUT, so go ahead and unmask it :)
merge the github PR; I'll take care of mplayer

Since Alexis added the mask I believe he can authorize its removal, so I
have done so:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=deb9d06fb461dc57291498b327e2eeb667444a5f

Thanks,
~Craig

[Alexis Ballier]

On Tue, 06 Nov 2018 11:04:17 -0500

Post by Craig Andrews

Post by Alexis Ballier
On Mon, 05 Nov 2018 20:38:58 -0500

Post by Craig Andrews
I think it's time to remove the mask on >=media-video/ffmpeg-4.0
ffmpeg 4 is in many distros (including Debian, Arch) and FreeBSD.
Upstreams are starting to require it, too. For example, Kodi 18 and
media-plugins/gst-plugins-libav-16 will require it.
The blocker issue https://bugs.gentoo.org/653678 has only 5
https://github.com/gentoo/gentoo/pull/10341
media-libs/mediastreamer
media-plugins/vdr-image
* 655442 and 658128 are for media-video/mplayer and fixed upstream,
requiring a new snapshot release
What do we say? Can we set a date when the hard mask will be removed?

I think 6 months qualifies for ETIMEOUT, so go ahead and unmask it :)
merge the github PR; I'll take care of mplayer

Since Alexis added the mask I believe he can authorize its removal,
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=deb9d06fb461dc57291498b327e2eeb667444a5f

I forgot to mention it, but you should probably have checked the re-kw
bug if any and created one after dropping keywords with broken deps :/