2007/8/25, Reinhard Tartler <[EMAIL PROTECTED]>:
> "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.
You can build them, yes. But if you don't have any of the recommended
packages installed you can do exactly one thing: querying the xine
version; every other action will fail / do nothing. Of course the
theoretical possibility of a frontend providing input, demuxer,
decoder and output plugin exists, but as there's no such frontend in
debian I don't consider this relevant.
That's why imho the severity is perfectly justified: the policy states
that a package and the stuff it "Depends:" should provide a
significant amount of functionality; but as said above it isn't useful
unless you install recommended packages.
> 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.
That choice is of no value if the system is broken anyway.
> > 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.
No, I did really mean "depend" in the sense of "Depends:". The
explanation and a very nice example (amarok) for that are in the
original mail.
> 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.
I don't mind seeing that as a feature; just that the other side of the
coin are (imho unacceptable) breakages.
> > 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.
That's the point where I fundamentally disagree.
> > 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 have that much time, sorry. But I can translate the stuff above a bit:
[ xineplug_vo_out_opengl.so xineplug_vo_out_xshm.so xineplug_vo_out_xv.so
xineplug_vo_out_xvmc.so xineplug_vo_out_xxmc.so ] : normal-x-plugins
[ xineplug_vo_out_xcbshm.so xineplug_vo_out_xcbxv.so] : normal-xcb-plugins
{ xineplug_vo_out_dxr3.so xineplug_vo_out_fb.so xineplug_vo_out_sdl.so
xineplug_vo_out_syncfb.so xineplug_vo_out_xdirectfb.so } : each of
those gets its own package; maybe fb and syncfb combined
You need a similar split of the audio outputs; all the remaining stuff
("none"-outputs, demuxers and decoders) would remain in the base
package (with hard dep of course).
> > 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
Christoph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
