Le dimanche 26 février 2006 à 14:07 +0100, Filippo Giunchedi a écrit : > > A package with a name python-foo will always provide the module foo for > > the default Debian Python version of the distribution. > > mmh that's tricky, CC'ing debian-python. > > my rationale behind python-bluez is that bluez is not the only bluetooth stack > for linux, indeed the bluetooth metapackage is provided to support not only > bluez. > I'm not sure what is the right way to go for python-bluetooth, following the > same scheme as packages it would be: > > python-bluetooth: depends python-bluez (and possibly others) > python-bluez: depends python2.3-bluez (or python2.4-bluez RSN) > > this would require every python bluetooth stack binding to provide the > "bluetooth" module (thus honouring the python policy) and of course being > uninstallable at the same time (which IMO is fine, as one wants to use only > one > bluetooth stack a time)
Wouldn't it more understandable with virtual packages? For example: python-bluez provides: python-bluetooth and conflicts: python-bluetooth python2.X-bluez provides: and conflicts: python2.X-bluetooth Regards, -- .''`. Josselin Mouette /\./\ : :' : [EMAIL PROTECTED] `. `' [EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
