[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#454162: libxine1-plugins: should not depend on libxine1-gnome

severity 454162 important

CC'ing debian-release for input
CC'ing debian-devel for further discussion among other developers

Hermogenes Hebert Pereira Oliveira <mandioca@nerdshack.com> writes:

> Trying to install xine-console I found myself having to
> install a lot of gnome-related packages also. Tracing the
> dependencies I discovered that libxine1-plugins _depends_
> on libxine1-gnome. Whatever the reasons are for this I think
> that I should be able to install xine without having to install
> such gnome-related packages. Maybe libxine1-plugins should
> only recommends, instead of depend on, libxine1-gnome.

Yes, this is a consequence of the fix for #439389, #437906, #437693 (and
probably other related bugs.)

Let me explain the issue: in stable, the package libxine1 shipped all
plugins in the libxine1 package, so you had every xine plugin installed
in any case. However, the dependencies where mostly Recommends (some as
Suggests). With lenny, it was decided to promote them to depends for
several reasons:

 - they are actually depends for the shared objects. Not installing the
   depends will make the xine plugin loader fail to load them, but this
   is not obvious to the user. He has to look at the debug log and see
   what plugin failed to load for what reason

 - the decision what plugin was 'important' enough for which level of
   dependency is not really clear. Some plugins (like the ffmpeg plugin)
   was a straight Depends, some a recommends some a suggest.

Since the promotion causes too many direct and indirect dependncies, it
was decided to split the plugins among several binary packages:

 - libxine1 - the xine video/media player library, binary files
 - libxine1-misc-plugins - Input, audio output and post plugins for libxine1
 - libxine1-console - libaa/libcaca/directfb related plugins for libxine1
 - libxine1-ffmpeg - mpeg related plugins for libxine1
 - libxine1-gnome - GNOME-related plugins for libxine1
 - libxine1-x - X11-related plugins for libxine1

plus an empty meta package, which depends on all plugins available:
 - libxine1-plugins - the xine video/media player library, meta package

The plan was to make libxine1 containing only the very essential core of
xine (not really useful for anything but building frontends). Frontend
packages are required to depend on the exact set of plugin packages they
need, e.g. an console based frontends like xine-console (aaxine, fbxine,
etc) have to depend on libxine1-console and X11 based frontends like
gxine have to depend on libxine1-x. This was announced to the libxine1
frontend maintainers in advance.

This plan has consequences for partial upgrades. Imagine that libxine1
was upgraded, but not the frontend package. This is entirly possible,
since libxine1 is unlikely to change the SONAME. However, since nearly
all plugins have been moved to seperate binary packages, this will lead
to degraded functionaliy like not being able to play mp3 files (since
the ffmpeg plugin has been moved to libxine1-ffmpeg), or not being able
to display video at all (since the x11/xcb plugins have been moved to

I was then told by several people (including a member of the release
team) that this issue was considered RC. Therefore it has been suggested
to make libxine1 to depend alternatively on libxine1-plugins OR
libxine1-misc-plugins. This way the user can choose if he wants a full
installation of xine (since libxine1-plugins drags in ALL dependencies),
or a more special installation (only core plugins and libxine1-x) is

This bug is now about that all plugins are installed by default,
dragging in too many dependencies at install/upgrade time. I have the
following compromise in mind, which I first want to be commented on
before I do the follwing changes:

a) Let's introduce 2 meta packages: libxine1-all-plugins, which depends on
all binary packages including libxine1-gnome, and another one
libxine1-common-plugins, which depends on all packages except

b) Additionally, the libxine1 package gets versioned conflicts against
all gnome/gtk2 related frontends in etch.

I'm personally not too happy with b), since I'd expect those frontends
to depend on the libgnomevfs2-0 anyways. OTOH, they don't depend on
libxine1-gnome either, so they will suffer in a lacking xine gnomevfs
and esd plugin. I'm listing it here because it has been suggested to me,
and while I'm not too happy with it, I'm not too strong on this point

Does the Release Team agree with the proposed changes? If yes, I'd like
to do them after xine-lib_1.1.8-3 migrates to testing (most likely for
the upload of 1.1.9-1, which has not been released upstream yet). If you
think this issue is RC, please bump severity of this bug #454162. I'll
then do an xine-lib_1.1.8-4 shortly.

Reinhard Tartler, KeyID 945348A4

Attachment: pgp4cYuujzkSQ.pgp
Description: PGP signature

Reply to: