--=-=-=
Content-Transfer-Encoding: quoted-printable


  I think we have enough packages in pkgsrc to warrant a new category
  for revision control programs and tools.

We had a lot of talk about the name of a new cagtegory, but no real
discussion on the wisdom of category changes, both in terms of a
cost-benefit analysis and in terms of what's wrong with pkgsrc and how
this relates.

Adding a new category means a bunch of cvs work.  It might help people
find things, but in general things belong in multiple categories and
browsing pkgsrc doesn't work very well.   So I don't see a huge
benefit.

One of the problems of pkgsrc is updating.  (One of the people on my
project is doing some work to help with this, so that a series of
'make replace' operations can become safe, but that's mostly
orthogonal to this.)   Besides all the problems of updating, almost
all the mechanisms are confused by category changes, since we have no
way to convey such changes (devel/subversion =3D=3D> vc/subversion) to
tools like pkg_chk (and the tools don't have the code to deal).

So, I think time would be better spent making the update process more
safe and automatic -- since the current status is a turnoff to pkgsrc
and also NetBSD.  But, we're talking about wiz's effort, so I don't
get to decide.  There is also the amount of extra time that a category
change will cause many pkgsrc users to spend on updates.

I object to a new category, and believe that the test for adding new
categories should be more like

  "Is the lack of the proposed category a real problem that outweighs
  the added grief of updating with tools that don't understand package
  renaming"

than

  "Are there enough programs to justify a category"


=2D-=20
        Greg Troxel <gdt@ir.bbn.com>

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (NetBSD)

iD8DBQFEt7SF+vesoDJhHiURAtIHAJ9hf6NwV13/ZIWIKyiRNUolMHws+QCggNks
4o38EPTw92ma89h4hysFS2M=
=HLVx
-----END PGP SIGNATURE-----
--=-=-=--