On Mon, May 22, 2006 at 10:07:00AM +0200, Goswin von Brederlow wrote: > Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes: > > Say you have a binary package (Multi-Arch: no) firfox and a > > library/plugin package firefox-mplayer-plugin. > > This could be handled by firefox having a "Provides: > > firefox-abiXX-arch-os-libc". Apt and perl for example already provide > > an abi pseudopackage. > After a lengthy discussion on irc Steve and I have come to the > conclusion that we don't seem to need a "Depends: foo:arch" syntax if > we instead implement versioned provides. More precisely, you don't need Depends: foo:arch if we have a suitably scalable solution that can be implemented using Provides. I.e., versioned Provides support is only a barrier to adoption to the extent that we have packages providing plugin interfaces, for which we want to support multiarch consumers, and the plugin interfaces rev frequently. > I think packages with a versioned depends on a provided package will > be uninstallable with the current dpkg, right? If so that would only > mean packages in etch+1 will be uninstallable without a prior update > to a dpkg that handles versioned provides. Yes. Having packages that can't be installed with previous-generation package management tools should be ok, it's only having packages that are installed when they shouldn't be that really becomes a problem. > Only the "dpkg:arch" is required and that can be done with "Provides: > dpkg-arch" again. Right. I wonder if even this should strictly be necessary, though, or if dpkg shouldn't be able to provide the needed features for build-essential in any architecture version... > So we don't have to change the syntax but we do have to change dpkg > to smooth the way ahead for etch+1. Yes. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature