[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Technical Committee: decision on #119517?

>>" " == Ian Jackson <ian@davenant.greenend.org.uk> 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.

 "...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   <srivasta@debian.org>  <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 debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: