Bug 277418 - multimedia/librtmp: Deprecate and set expiration date to 2023-04-30
Summary: multimedia/librtmp: Deprecate and set expiration date to 2023-04-30
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Hiroki Sato
URL:
Keywords:
Depends on: 277419
Blocks:
  Show dependency treegraph
 
Reported: 2024-03-01 17:33 UTC by Daniel Engberg
Modified: 2024-03-19 20:18 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (hrs)


Attachments
Patch for librtmp (416 bytes, patch)
2024-03-01 17:33 UTC, Daniel Engberg
no flags Details | Diff
librtmp-2.6.patch (20.42 KB, patch)
2024-03-05 03:55 UTC, takefu
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Engberg freebsd_committer freebsd_triage 2024-03-01 17:33:37 UTC
Created attachment 248853 [details]
Patch for librtmp

This library has been on life support since it was adopted by the FFmpeg project and upstream has no longer intentions of keeping it alive [1].
Functionality has been folded into FFmpeg or consumers have moved on to other projects and/or dropped support. Move repos have already dropped this library [2].

1. http://git.ffmpeg.org/gitweb/rtmpdump.git/commit/52746d7c5246c4d07d98921e6415de7b4c34c927
2. https://repology.org/project/librtmp/versions
Comment 1 Felix Palmen freebsd_committer freebsd_triage 2024-03-01 20:02:22 UTC
Looking how the latest commit seems to announce a new release (v2.6), I have doubts about "no intentions keeping it alive":
https://git.ffmpeg.org/gitweb/rtmpdump.git/commitdiff/6f6bb1353fc84f4cc37138baa99f586750028a01

Also as of now, removing it would break other ports, it's even in the dependency tree of multimedia/mpv with default options.
Comment 2 Daniel Engberg freebsd_committer freebsd_triage 2024-03-01 20:09:05 UTC
Did you read the commit which I linked too (and committed the very same day)?

I'll take care of the tree mentioned in PR 277419 and it's an incorrect dependency as mpv uses ffmpeg.

See stream/stream_lavf.c in mpv's sources

Best regards,
Daniel
Comment 3 Felix Palmen freebsd_committer freebsd_triage 2024-03-03 13:02:02 UTC
(In reply to Daniel Engberg from comment #2)
> Did you read the commit which I linked too (and committed the very same day)?
Sure I did. It doesn't express any intentions, neither positive nor negative, and just describes the limitations of the current state. Publishing a new version number in a following commit really doesn't suggest an intention of letting it die.

> it's an incorrect dependency as mpv uses ffmpeg.
It's an indirect dependency for some youtube-download functionality.
Comment 4 Daniel Engberg freebsd_committer freebsd_triage 2024-03-03 13:37:19 UTC
Except that OpenSSL 3.0 isn't going to be around forever and is going to be a troublesome dependency as all OpenSSL libraries are.

As for the Youtube functionality it relies on yt-dl(p) which have been using FFmpeg since several years and is deprecated (I'll submit a PR about that).
See ./work/mpv-0.37.0/player/lua/ytdl_hook.lua
https://github.com/yt-dlp/yt-dlp?tab=readme-ov-file#deprecated

www/youtube_dl should be sunset in favour of www/yt-dlp due to many things being broken or performing poorly.
Comment 6 Daniel Engberg freebsd_committer freebsd_triage 2024-03-06 20:49:42 UTC
I'm fine with updating and deprecating it however why should we roll our own tarball when its unnecessary?
Comment 7 Felix Palmen freebsd_committer freebsd_triage 2024-03-06 21:00:28 UTC
(In reply to Daniel Engberg from comment #4)
> Except that OpenSSL 3.0 isn't going to be around forever and is going to be a
> troublesome dependency as all OpenSSL libraries are.
Then again, the commit message just describes the current limitations, it doesn't say this will never be fixed.

> As for the Youtube functionality it relies on yt-dl(p) which have been using
> FFmpeg since several years and is deprecated ...
Not sure whether that's what you meant, but what's deprecated there is using rtmpdump ... which is fine, still I see no pressing need to deprecate the respective port. It isn't abandoned upstream, there's activity and even a new release.

Don't get me wrong, I see no pressing need to keep it either (given more popular ports like mpv won't suffer, seems this can be done), but then, that's for the maintainer to decide, right? :)

> www/youtube_dl should be sunset in favour of www/yt-dlp due to many things
> being broken or performing poorly.
Sure!
Comment 8 commit-hook freebsd_committer freebsd_triage 2024-03-19 20:18:30 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=ee4b66a8d9e92c6e53cd54ae5ece27ea5f4813e7

commit ee4b66a8d9e92c6e53cd54ae5ece27ea5f4813e7
Author:     Daniel Engberg <diizzy@FreeBSD.org>
AuthorDate: 2024-03-19 18:55:04 +0000
Commit:     Daniel Engberg <diizzy@FreeBSD.org>
CommitDate: 2024-03-19 20:17:24 +0000

    multimedia/librtmp: Deprecate and set expiration date to 2024-04-30

    Depends on legacy functionality of OpenSSL and superseded by
    multimedia/ffmpeg

    PR:             277418
    Approved by:    portmgr (maintainer timeout, 2+ weeks)

 multimedia/librtmp/Makefile | 3 +++
 1 file changed, 3 insertions(+)