"Christoph Pfister" <[EMAIL PROTECTED]> writes: > Package: libxine1 > Version: 1.1.7-2 > Severity: serious
First of all, I don't consider this RC, rather minor. However as you write: > 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). I agree to keep it at this level for now, until I hear opinions of the Release Team. > 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. You can e.g. build frontends without the plugins. The current situation allows to remove packages, which a user might not want to have installed for one reason or the other. My point is that the user currently can choose better what to remove. Promoting them to depends removes the choice. > 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. I assume you wanted to write "rely" instead of "depend" in the sentence above. Well, I don't think this should be a problem. Right, users can remove the dependencies in a way they loose functionality if they do so. I consider this rather a feature than a bug, see above. > 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. Right, this is expressed correctly via the Recommends relationship in the xine binary packages. > 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. I agree that this is problematic, but because of other reasons than you describe here. I had a /query with sam about this, and I've come to the conclusion that this is a more general bug which should be adressed in apt. But that's another bug, so I won't further comment on this here. > 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, ...). Can you please work out a list of binary packages and their contents how you see them fit? I'd like to discuss the list of packages with the ftp team before uploading them to debian. > 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. Thank you for your opinion on this, I'm aware of this argument. You can help me on this point by proposing a list of binary package along with their file contents. I'd really like to work out a sensible and consisten policy for xine plugins. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
