>>" " == Ian Jackson <[EMAIL PROTECTED]> writes:
> Anthony Towns writes ("Re: Technical Committee: decision on #119517?"):
>> On Thu, May 02, 2002 at 03:31:18PM -0500, Manoj Srivastava wrote:
>> > In this particular case, you got me. In the general case,
>> > though, I still think my arguments have merit.
>>
>> Right, but that's kind-of the point: in the general case this isn't an
>> issue, since everyone recognises it's a bad thing to do and there're
>> very few cases where fixing it would actually be worse.
> So, let me just see if we all have a shared understanding now. I may
> have misread Manoj's comments (and subsequent clarification) - if so,
> let me know, Manoj.
> 1. We think that in general it's a bad thing for programs to fail
> because of missing stuff that was only in an optional dependency (ie,
> Recommends or Suggests rather than Depends).
With you so far.
> 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. 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.
The only other argument I see is that It Is Too Much Work;
which again I reject, for non broken programs are worth a one time
packaging effort.
> 3. With respect to cardinfo, we agree with the maintainer that the
> decision is at least plausibly correct in this case. (NB that we
> would need a 3:1 majority to overrule the maintainer.)
I certainly do not agree wit h the maintainer; I think what
Dale suggested (splitting the package) is the correct remedy.
> There's just one thing left to consider: do we think the current
> contents of the policy manual is adequate ? If not then perhaps
> we should ask the policy group to try to incorporate something
> like my points 1 and 2 in an appropriate place. Also, perhaps we
> should review what the manual currently says.
I think that 1 should probably go in, I am against 2 being
made policy.
manoj
--
"...what's the point of ... new technology if you can't find some way
to pervert it?" Effinger, "Marid Changes His Mind", IASFM, 1/90
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
