Re: Technical Committee: decision on #119517?
Manoj Srivastava writes ("Re: Technical Committee: decision on #119517?"):
> Ian Jackson <ian@davenant.greenend.org.uk> writes:
> > 2. However, there are circumstances where it is less of a bad thing
> > than the available alternatives, so we can't make a hard and fast rule
> > that it should never be done that way. For example, it is sometimes
> > not worth creating a separate package just for some peripheral program
> > or feature, and in this case Suggests or Recommends should be used, as
> > appropriate.
>
> I am afraid I am not yet convinced. [...]
Now I'm not sure I follow you. Are you unconvinced that
(a) we can't make a hard and fast rule
(b) my example is useful or interesting or
(c) that the maintainer made the tradeoff correctly in this case ?
Earlier, you replied to Anthony:
Anthony Towns <aj@azure.humbug.org.au> writes:
> "Hey why doesn't cardinfo work?"
> "It's an X program and you don't have X installed."
> Doesn't seem particularly hard? (Seems a lot easier than
> explaining it to the cognoscenti tbh... :)
...
In this particular case, you got me. In the general case,
though, I still think my arguments have merit.
If you didn't mean that you were now convinced that the situation wrt
cardinfo was reasonable, what did you mean ? What about the argument
introduced by AJ - that even if we changed the dependencies to prevent
people installing pcmcia-cs including cardinfo without xlib6g, it
still wouldn't work, just giving a different error message ? Do you
think that is also an unacceptable situation ?
> The argument that we have too many packages already does not
> hold water; indeed, we have so many packages that the few created
> in these rather rare (we are all agreed that this is an unusual
> circumstance, correct?) would not make a perceptible difference.
> We _have_ to come up with mechanisms to make the burgeoning
> packages palatable to users, and improve discovery and selection
> methods.
I agree that we need better mechanisms for dealing with our many
packages. But:
(i) Those mechanisms don't exist yet, and until they do, the current
situation with cardinfo is better than the available
alternatives.
(ii) Even with better mechanisms for handling many packages,
additional packages still impose costs. Not just performance
problems, but management and information problems too. These
can be mitigated by better automation, but automation itself has
costs and can't completely eliminate the problems it addresses.
For these reasons it seems to me that creating additional packages is
a bad idea unless there's a good reason. And, as you know, I remain
unconvinced that there is a good reason here: the actual bad
consequences of this installation situation are negligible, and point
easily to the remedy.
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: