severity 454162 important stop 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 libxine1-x). 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 preferred. 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 libxine1-gnome. 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 here. 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. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
Attachment:
pgpdSSTCfKuvD.pgp
Description: PGP signature