--pgp-sign-Multipart_Sun_Jul_16_12:09:03_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Sun, 16 Jul 2006 00:48:25 +0200,
Thomas Klausner wrote:
>=20
> On Fri, Jul 14, 2006 at 11:13:09AM -0400, Greg Troxel wrote:
> > 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.
>=20
> Well, I disagree. I think it does make finding packages easier
> if the are in a properly named category.

I think given the number of available packages it's safe to say that,
except for experts, one needs to use search tools to find packages.
This was probably true back when there were 1,000 or fewer packages.

The actual location of a package within the categories structure is more
or less useless, sometimes even for experts.  I find myself doing greps
of "*/*/DESCR" all the time to find things, even when I've worked on the
package I'm looking for before!


> Even I didn't have an overview of how many packages related to
> version control we already have in pkgsrc, but once they are in
> one category, it's much quicker to see this.

Then you need some kind of decent query tool to search the INDEX file!


> Just adding a virtaul category entry in CATEGORIES is not the same.

Well there are already many (2065) packages with multiple CATEGORIES
specified.  Do you somehow expect to use only "ls" to see what packages
are in any given category?  If so then you've lost that ability a very
long time ago (right from the beginning, I dare say).

I.e. adding a virtual category entry is _exactly_ the same as what we
have now!  How many packages are in the x11 category?  (hint:  an awful
lot more than are in the x11 sub-directory!)

Are there not also already virtual category entries?  (I'm to lazy to do
that query to find out for myself :-))

For the purposes of categorization alone it really shouldn't matter if
al packages lived only in one sub-directory with all categories being
virtual.

(There should be a package category registry though, complete with a
detailed description of the category as well as a list of rules to help
decide what kinds of things should be included in that category.)

Packages should _never_ have to move between categories (assuming
they're first put in any even remotely logical place).

There is still the issue of renaming packages within a category, and I
agree that logically there's no difference if a package is moved to
another category as part of, or as the reason for, a rename, but even
that should happen only if absolutely necessary and as rarely as
possible.  There are far more dependencies on the full package directory
names than just the one "pkg_chk" tool.  Adding another level of
indirection through some lookup table to all those tools and components
is something that does need careful design and planning.

(this isn't about CVS either -- that's the very least of the issue!)


> We could note the move in the package Makefiles themselves, and
> add that in a variable for the binary packages.

Well it shouldn't be in the CHANGES file(s) -- that's not intended to be
parsed, IIUC.  Some kind of directed graph is needed I think.  A farm of
symlinks would work nicely, and would be quite useful to both tool and
human use, though we'd need a tool to create it from some more rational
relational table I think, perhaps from rules in the Makefiles.

One really excellent way to implicitly and explicitly limit the number
of renames and relocates would be to keep the old directory in the
pkgsrc tree, containing just a Makefile that pointed to the next newer
directory.  The more I think about it the more I like it.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Sun_Jul_16_12:09:03_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: ObCKE14ibRyxXNX1Snww3qiVINEWaahU

iQA/AwUBRLpkoWJ7XxTCWceFEQL5JACfeHJ/295IV3naiBfc7cu3FLcxQsgAoMzW
hxlBpkFEULRcCpZO1Zbz4X2/
=aGKy
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Sun_Jul_16_12:09:03_2006-1--