Bug#717076: libjpeg draft resolution
* Kurt Roeckx (kurt@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
Reply to: