ffmpeg aleady ships generic libav*-extra packages that depend on the latest versions. It would be desirable to also ship non-extra versions of these. Thanks! Martin-Éric
Am 2024-11-06 10:53, schrieb Martin-Éric Racine: Could you elaborate your use case, please? The non-extra variants of the shared library packages are installed by default, i.e. they are first choice in the list of alternative dependencies that shlibdeps creates. The -extra dummy packages are there to make sure that the extra variants of the libraries are preferred. So, what would be the use case of a non-extra package? - Fabian
ke 6. marrask. 2024 klo 13.50 Fabian Greffrath (fabian@greffrath.com) kirjoitti: are as follow: Depends: libc6 (>= 2.30), libasound2, libatk-bridge2.0-0, libatomic1, libgbm1, libglib2.0-0, libgtk-3-0, libnss3, libxshmfence1, libxss1, libxtst6, xdg-utils, libayatana-appindicator3-1 Recommends: libavcodec58 | libavcodec-extra58 | libavcodec57 | libavcodec-extra57 | libavcodec-ffmpeg56 | libavcodec-ffmpeg-extra56 | libavcodec54 | libavcodec-extra-54, libavformat58 | libavformat57 | libavformat-ffmpeg56 | libavformat54 That long Recommends would make more sense if it were: Recommends: libavcodec | libavcodec-extra, libavformat | libavformat-extra Replacing all the *-extra with the metapackage already is possible. Replacing the non-extra ones is not. Martin-Éric
Am 2024-11-07 11:04, schrieb Martin-Éric Racine: I see, so this is about dlopen()ed shared libraries. Thanks for the example! - Fabian
to 7.11.2024 klo 12.13 Fabian Greffrath (fabian@greffrath.com) kirjoitti: Welcome. Has there been any progress on this? Martin-Éric
Am 2025-03-11 15:46, schrieb Martin-Éric Racine: Nope, but I'd volunteer to work on this. What name scheme do you suggest for the packages, libav*-nonextra or libav*-regular or anything else? - Fabian
Please don't. I don't think that we should support this use case in the archive. If a package supports dlopening multiple versions of libav libraries, then that can and should be expressed in their Depends to make it clear which version that they support. On a different note, the dependencies of the spotify package are unnecessarily complex since none of the -extra variants are needed to be listed there. The -extra meta package is there to help users to get the -extra variants where they exist. But Cheers
Am 2025-03-13 11:58, schrieb Sebastian Ramacher: Hmkay. Now it got interesting... ;) - Fabian
to 13.3.2025 klo 12.10 Fabian Greffrath (fabian@greffrath.com) kirjoitti: libavcodec, libavcodec-extra, libavformat, libavformat-extra, libavutil With each of the above depending on the matching currently available version. Looking at what's currently in unstable these would respectly depend on: libavcodec61, libavcodec-extra61, libavformat61, libavformat-extra61, libavutil59 Martin-Éric
Am Donnerstag, dem 13.03.2025 um 11:58 +0100 schrieb Sebastian Ramacher: Could you reveal the second half of the last sentence, please? - Fabian
The "But" is a left over from a sentence moved elsewhere. Cheers
tags 1086805 + wontfix close 1086805 thanks
ti 12.8.2025 klo 23.39 Sebastian Ramacher (sramacher@debian.org) kirjoitti: This bus was marked as wontfix and closed without any explanation. Martin-Éric
ke 13.8.2025 klo 9.42 Fabian Greffrath (fabian@greffrath.com) kirjoitti: That's not an explanation. That's a cop-out. Martin-Éric
Am 2025-08-13 07:17, schrieb Martin-Éric Racine: Sebastian provided some rationale here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086805#35 - Fabian
Take it or leave it. Version-less binary packages create more problems than they solve (if they solve any at all). There is a good reason we have a whole section in the Debian policy on managing shared libaries. I am closing this bug again. Cheers