* Kurt Roeckx (k...@roeckx.be) [140322 01:39]: > On Fri, Mar 21, 2014 at 11:38:15PM +0000, Ian Jackson wrote: > > In general I worry that your interpretation of resolution texts > > focuses far too much on the exact words used, and far too little on > > the substance of the underlying issues. > > > > In this particular case we have two packages both of which want to > > claim the libjpeg-dev virtual package name, which for technical > > reasons ought to be provided by only one of them. Clearly this is a > > question of overlapping jurisdictions. > > My understanding is that the point of virtual packages is so that > several *can* provide it. But you're now telling 1 package that > it can't do that, while you instead could say only one (other) > package can do it in this case.
Well, there are two use-cases of virtual packages. One is multiple packages providing the same service, like mail-transfer-agent. This is typically the case with non-development/library-packages. The other is to provide a development-interface, so that switching from foo(n) to foo(n+1) is easier. In that case, only one of these packages may provide the foo-dev-interface package, because we want to predict which package is used while building with foo-dev. This is typically the case with development/library-packages. Though I'm currently thinking if it wouldn't be better to do a slim "real" package, because it would also make the autobuilders more happy. But that (using a virtual package this way, or a real) is IMHO setting technical policy, which is also within the domain of the tech ctte (and if you read 6.1.1, it seems that we can there make a technical decision even if developers decided different initially without requiring a 3:1-majority). > The difference in my view is that you decide between how a set of > related packages should interact with each other or that you > prevent 1 package from following the normal rules. I have no > problem interpreting the first case as falling under 6.1(2), > but I'm not yet sure about the second. If the policy for development packages would be that usually many of them provide the same virtual -dev-package and we would like to kick one out via explicit directive to the maintainer "drop that virtual package", I would agree with you. However, the normal rules here are that only one provides it, so I think we are at the first case. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org