Package: libxine1
Version: 1.1.7-2
Severity: serious
Most of the dependencies were turned into "Recommends:" beginning with
version 1.1.7-2. This renders the package unusable for almost
(possibly that there's exception; but I can't imagine any) every user
of the library; except for those people who install the recommended
packages by default.
The issue is that even with the announced change of apt to install
those packages by default this problem will not be solved
sufficiently. The root of the trouble is that although those
dependencies aren't absolute for xine-lib itself many of them are
needed by the users of the library. And the main point is: those users
can't depend on those.
There are basic reasons for that: The users don't access those
libraries directly, they don't know which libraries are needed and
even less which version; all that stuff is internal to xine and
therefore only libxine can deal with those dependencies correctly.
For example an X output plugin: all the user knows is that it is an X
plugin - something around 20 lines in the header is shared between the
plugin and the user - but it doesn't know whether shm, xv, xvmc,
opengl, sdl etc is used. Even less it knows which additional libraries
are needed for those plugins to work.
In the current situation it is very easy to create gentoo-like breakages [1].
For the solution: Because this issue can't be solved at other places
than libxine (as an example: it would be wrong for amarok to depend on
libmodplug0c2 to allow playing mp3 files; and it's equally wrong if
you can't play those files because of the way libxine deals with
dependencies [2]), there are two possible approaches:
1) Revert to the old way and using "Depends:". I know that you don't
like that idea; but on the other hand I wonder why you don't find the
current recommends-way-of-doing-things problematic.
2) Split the output plugins into different packages, like
libxine1-xxx-all (which depends on the others and is installed by
default) and libxine1-xxx-<name-of-plugin>, which hard depends on the
needed stuff. You could do the following split: normal-x-plugins (shm,
xv, xvmc, gl), normal-xcb-plugins (shm, xv) and for each of the
special ones one package (sdl, dfb, ...). I don't see much sense in
splitting the demuxers / decoders (apart from legal reasons; but in
this case you'd have to rip away the offending stuff from the source
anyway). I think it's just annoying for most users to only have a
half-baken/"codeced" system.
I made the bug report rc to prevent this package from entering testing
until this issue hasn't been fully solved (to avoid needless annoyance
for users).
Christoph
[1] attached
[2] discussion on #debian-qt-kde; Debian Qt/KDE Team can confirm that
[OUCH!!] There are no input plugins.
xine needs at least one input plugin, but none is installed.
You should probably reinstall xine-lib...
press <enter> to continue...
[OUCH!!] There are no demux plugins.
xine needs at least one demux plugin, but none is installed.
You should probably reinstall xine-lib...
press <enter> to continue...
[OUCH!!] There are no decoder plugins.
xine needs at least one decoder plugin, but none is installed.
You should probably reinstall xine-lib...
press <enter> to continue...
[OUCH!!] There are no video_out plugins.
xine needs at least one video_out plugin, but none is installed.
You should probably reinstall xine-lib...
press <enter> to continue...
[OUCH!!] There are no audio_out plugins.
xine needs at least one audio_out plugin, but none is installed.
You should probably reinstall xine-lib...
press <enter> to continue...
