Hi! I thought of another solution, which addresses Reinhard's comment about packages build-depending on libxine-dev suddenly gets harder to built when caught in transitions - and still have proper depends which - makes the users of the xine frontends happy - makes britney enforce that the stuff using e.g. flac gets in at the same time with flac if flac bumps from flac1 to flac2 - makes me happy
And it can be combined with the earlier mentioned solution about having a depends on xine-plugins-all | xine-plugin with all plugins providing xine-plugins My idea goes as followed: Invent a new package: libxine1-lib. This is a exact copy of the current libxine1. Except a little modified shlibs file! (This is very very important that the shlibs file in libxine1-lib points to libxine1 | libxine1-lib, maybe versioned) Have libxine1 being a empty package that depends on all the relevant plugins (either directly or as a xine-plugin-all|xine-plugin solution) and on libxine1-lib. Other packages still depends on libxine1, but will on their next build depend on libxine1 | libxine1-lib. having libxine-dev depend only on libxine1-lib makes the buildds not install all the plugins for the fun of it. And people can now remove the plugins they don't want by also removing the libxine1-package (which is now a empty package) Questions welcome. /Sune -- How may I click the gadget from Office 9.5? The point is that from the folder inside Outlook you either should rename a clock, or need to remove from the ADSL button in order to enable the TCP/IP parallel port on a clock.
signature.asc
Description: This is a digitally signed message part.
