Subject: Re: New category for revision control tools and programs
To: Greg Troxel <firstname.lastname@example.org>
From: Thomas Klausner <wiz@NetBSD.org>
Date: 07/16/2006 00:48:25
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
Well, I disagree. I think it does make finding packages easier
if the are in a properly named category.
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.
Just adding a virtaul category entry in CATEGORIES is not the same.
> 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 ==> vc/subversion) to
> tools like pkg_chk (and the tools don't have the code to deal).
I agree that this is a problem and should be fixed. So let's discuss it.
But I think it's a related, but separate discussion.
pkg_chk needs to know when a package moves from foo/bar to foo2/bar.
It could rather easily be taught to parse the "Moved" and "Renamed" entries
in pkgsrc/doc/CHANGES*, when these are available.
I'm not yet sure what to do when they are not available, i.e. how
does pkg_chk know that a binary package bar-1.2.tgz from foo2/bar
is a suitable replacement for updating bar-1.1.tgz from foo/bar?
We could note the move in the package Makefiles themselves, and
add that in a variable for the binary packages.
Does anyone have other ideas?
The other place that should handle this is the bulk bild code
for site specific packages.
It always has the CHANGES* files, so it's easier to solve there.
Just add a warning for the user that instead of the non-existing
foo/bar, foo2/bar will be used, and that the user should fix it
in the mk.conf file...