Bug#439389: dependency changes break other packages
2007/8/25, Christoph Pfister <[EMAIL PROTECTED]>: > > > 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. I have to take that back partly. It's possible to use some raw / very special formats (video: rgb, yuv, bitplane over fb; audio: gsm610, dvaudio, nsf, pcm over oss). Only "partly" because I don't consider that useful enough. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439389: dependency changes break other packages
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-, 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 } :
Bug#439389: dependency changes break other packages
Sune Vuorela <[EMAIL PROTECTED]> writes: > On Saturday 25 August 2007, Reinhard Tartler wrote: >> 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 thought of doing it the same way as with the X input drivers and X video > drivers - having all the plugins you can choose from > Provide: xine-plugin > > and creating a xine-plugins-all package which depends on all the individual > plugins in the same way as xine did a couple of versions ago. > > Then make libxine1 depend on xine-plugins-all | xine-plugin > > This way, when people install xine, they get all the plugins installed, but > are free to remove them later without removing xine. Yes, you told me that proposal already on IRC, and I signaled that I like this solution. > I think it will work, but I haven't thought it fully thru yet. And I've already asked you on irc and in the mail you've referenced to do this. I'm more than happy to hear your proposal. Its not that I'm not thinking about this since I've introduced libxine1-ffmpeg and co :/ -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439389: dependency changes break other packages
On Saturday 25 August 2007, Reinhard Tartler wrote: > 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 thought of doing it the same way as with the X input drivers and X video drivers - having all the plugins you can choose from Provide: xine-plugin and creating a xine-plugins-all package which depends on all the individual plugins in the same way as xine did a couple of versions ago. Then make libxine1 depend on xine-plugins-all | xine-plugin This way, when people install xine, they get all the plugins installed, but are free to remove them later without removing xine. I think it will work, but I haven't thought it fully thru yet. /Sune -- Man, do you know how could I cancel a controller? You should never turn off the space bar. signature.asc Description: This is a digitally signed message part.
Bug#439389: dependency changes break other packages
"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-, 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]
Bug#439389: dependency changes break other packages
On Friday 24 August 2007, Christoph Pfister wrote: > 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. A quick quote from policy about Depends: The `Depends' field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. (7.2) I think the set of most used plugins falls into this category. "a significant amount of functionality". I haven't been able to use xine for anything with only the depends installed. /Sune -- I cannot reset the POP3mail terminale of the forward from Office 5.6, how does it work? From the file menu within Office you either can't click a OpenGL prompt, or can't telnet on the clock of the URL on the 47-inch IDE processor. signature.asc Description: This is a digitally signed message part.
Bug#439389: dependency changes break other packages
Package: libxine1 Version: 1.1.7-2 Severity: serious 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. 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. 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. For example an X output plugin: all the user knows is that it is an X plugin - something around 20 lines in the header is shared between the plugin and the user - but it doesn't know whether shm, xv, xvmc, opengl, sdl etc is used. Even less it knows which additional libraries are needed for those plugins to work. In the current situation it is very easy to create gentoo-like breakages [1]. 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. 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-, 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, ...). 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. 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). Christoph [1] attached [2] discussion on #debian-qt-kde; Debian Qt/KDE Team can confirm that [OUCH!!] There are no input plugins. xine needs at least one input plugin, but none is installed. You should probably reinstall xine-lib... press to continue... [OUCH!!] There are no demux plugins. xine needs at least one demux plugin, but none is installed. You should probably reinstall xine-lib... press to continue... [OUCH!!] There are no decoder plugins. xine needs at least one decoder plugin, but none is installed. You should probably reinstall xine-lib... press to continue... [OUCH!!] There are no video_out plugins. xine needs at least one video_out plugin, but none is installed. You should probably reinstall xine-lib... press to continue... [OUCH!!] There are no audio_out plugins. xine needs at least one audio_out plugin, but none is installed. You should probably reinstall xine-lib... press to continue...
