Bug#410426: xine-lib: misleading package descriptions
Am Samstag, den 10.02.2007, 21:39 +0100 schrieb Reinhard Tartler: Yes, the selection is indeed quite random. The main motivation for the split was to promote the dependencies from 'Recommends' to 'Depends'. In order to not get too many dependencies from libxine1 (which has a lot of reverse depends), I moved some plugins to seperate packages. I tried to keep the libxine1 package functional, without imposing too many and 'heavyweight' dependencies. This sounds rational, maybe the plugin selection for the packages could be motivated like this: - The `libxine1' package contains all plugins which do not pull in further dependencies, except those who are expected on a desktop system anyway (e.g. libogg*, libvorbis*, libtheora*). [Did you notice that libxine1 has dependencies on libxine1?] - The `libxine1-ffmpeg' contains all plugins which pull in further dependencies, which may not be part of a minimal installation. However, the suffix `-ffmpeg' would be inappropriate and not describe the package's contents. Something like `libxine1-extras' might fit better. I think this is similar to the way the gstreamer maintainers split up their plugin packages (see README.Debian and HACKING.Debian in the `gst-plugins-base0.10-0.10.10' tarball). By the way, the separation of KDE- and GNOME-related plugins was the best idea anyway! ;) Yes, this is indeed necessary. Perhaps you can make some suggestions for that? Sure! As soon as the criteria for the plugin selection are defined. ;) Thanks again for your report! Thanks for your great work on this package! Nice greetings, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410426: xine-lib: misleading package descriptions
package: xine-lib version: 1.1.4-2 severity: minor tags: experimental Hello, since the split-up of the `libxine1' package the short descriptions of the fragmented packages are misleading. Now all of them are `the xine video/media player library, binary files' without further explanation. Secondly, in the new package's description there is a dot `.' visible where it should most propably show an empty line. Thirdly, the selection of plugins which make it into `libxine1' and `libxine1-ffmpeg' seems quite random: In `libxine1-ffmpeg' there is the `xineplug_decode_mad.so' plugin which obviously has nothing to do with ffmpeg itself. The same applies to the a52 and dts plugins. Now, one might think that this package is for input plugins in general, maybe even for decoding of patented formats (i.e. mp3). But then there are even more input plugins in `libxine1', like those for vorbis. And, more puzzling, there are even the plugins for decoding of real-audio etc. Maybe I get something wrong, but could you please clean up the packages' descriptions to explain more precisely what kind of codecs they contain and why they do? Thank you very much! Nice greetings, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410426: xine-lib: misleading package descriptions
Fabian Greffrath [EMAIL PROTECTED] writes: package: xine-lib version: 1.1.4-2 severity: minor tags: experimental Thanks for your bug report! since the split-up of the `libxine1' package the short descriptions of the fragmented packages are misleading. Now all of them are `the xine video/media player library, binary files' without further explanation. Oh, you're right. I'll fix the description in the next upload Secondly, in the new package's description there is a dot `.' visible where it should most propably show an empty line. I'll have a log Thirdly, the selection of plugins which make it into `libxine1' and `libxine1-ffmpeg' seems quite random: In `libxine1-ffmpeg' there is the `xineplug_decode_mad.so' plugin which obviously has nothing to do with ffmpeg itself. The same applies to the a52 and dts plugins. Now, one might think that this package is for input plugins in general, maybe even for decoding of patented formats (i.e. mp3). Yes, the selection is indeed quite random. The main motivation for the split was to promote the dependencies from 'Recommends' to 'Depends'. In order to not get too many dependencies from libxine1 (which has a lot of reverse depends), I moved some plugins to seperate packages. But then there are even more input plugins in `libxine1', like those for vorbis. And, more puzzling, there are even the plugins for decoding of real-audio etc. I tried to keep the libxine1 package functional, without imposing too many and 'heavyweight' dependencies. Maybe I get something wrong, but could you please clean up the packages' descriptions to explain more precisely what kind of codecs they contain and why they do? Yes, this is indeed necessary. Perhaps you can make some suggestions for that? Thanks again for your report! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpvYFSa9bML9.pgp Description: PGP signature
