Debian Bug report logs - #1091817
libmlt7: Could the plugins be split into multiple packages?

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Guillem Jover <[email protected]>

To: [email protected]

Subject: libmlt7: Could the plugins be split into multiple packages?

Date: Tue, 31 Dec 2024 20:55:57 +0100

Package: libmlt7
Version: 7.28.0-2
Severity: wishlist

Hi!

This package contains all the plugins for MLT, which end up pulling
lots of potentially unrelated dependency trees, including current and
deprecated stacks (see #1038506 for an example involving SDL1).

I noticed this while checking for Qt5 reverse dependencies, and then
pondered whether the plugins could instead be split into plugin packages,
probably by group of functionality or stack. Although I'm not sure how
the plugin system works and whether users of the library need to
explicitly opt-in, or whether the modules are autoloaded, or selected
through a config for the library itself or similar, and whether they
provide alternative implementations for the same functionality.

So depending on the above, this could imply a transparent transition
where the packages get split and the library pulls them through either
Recommends, or only Depends on a virtual package and a main alternative
(for example libmlt-plugins-video or libmlt-plugins-audio, provided by
the various relevant plugin packages) and that's it; or one where it
needs multiple stages, with say a first split and making the library
depend on everything, then update reverse dependencies to depend on the
specific plugins they explicitly use, and then lower the plugin
dependencies from the library to Recommends for example, or some other
alternative transition path.

Assuming the idea of splitting is acceptable, here could be a rough
separation with a draft naming proposal (this might need more thought
though), based on their dependencies [D]:

  libmlt-plugins-core
    libmltcore.so
    libmltdecklink.so
    libmltfrei0r.so
    libmltnormalize.so
    libmltkdenlive.so
    libmltoldfilm.so
    libmltresample.so
    libmltxine.so

    Although perhaps while at it, some of these could also be split
    on their own packages so that users explicitly depend on them,
    and in case they grow transitive dependencies then that's already
    sorted, or if the plugins need to be eventually removed by
    upstream it's easier to know what that will affect.

    From those, perhaps xine and kdenlive and frei0r would deserve to
    be split, as being non-generic or stack related?

  libmlt-plugins-xml
    libmltxml.so

  libmlt-plugins-ui-gtk
    libmltgdk.so

  libmlt-plugins-ui-qt5
    libmltqt.so
    libmltglaxnimate.so

  libmlt-plugins-ui-qt6
    libmltqt6.so
    libmltglaxnimate-qt6.so

  libmlt-plugins-ui-sdl1
    libmltsdl.so

  libmlt-plugins-ui-sdl2
    libmltsdl2.so

  libmlt-plugins-video-ffmpeg
    libmltavformat.so

  libmlt-plugins-video-movit
    libmltmovit.so

  libmlt-plugins-video-opencv
    libmltopencv.so

  libmlt-plugins-video-plus
    libmltplus.so
    libmltplusgpl.so

  libmlt-plugins-video-vidstab
    libmltvidstab.so

  libmlt-plugins-audio-jack
    libmltjackrack.so

  libmlt-plugins-audio-rtaudio
    libmltrtaudio.so

  libmlt-plugins-audio-rubberband
    libmltrubberband.so

  libmlt-plugins-audio-sox
    libmltsox.so

  libmlt-plugins-audio-vorbis
    libmltvorbis.so


[D] for so in /usr/lib/*/mlt-7/*.so; do \
      objdump -p $so | grep -E 'file format|NEEDED'; \
    done

Thanks,
Guillem

Send a report that this bug log contains spam.