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


Thomas Klausner <wiz@NetBSD.org> writes:

> 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.
>
> 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.

There is some benefit, but the rela issue is comparing that to the cost.

> 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.

It's not totally separate because the answer to the renaming cost/benefit
question has to be in the context of the current state of support for
renamed packages.

> 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" entri=
es
> 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?

Clearly :-) there needs to be something that builds a file for pkg_chk
to use that has this information....  This can be part of the summary
information that seems to be used now.

> 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...

Sounds ok.  But I think we should aim high - the right behavior is to
be able to, on some system with missing or outdated pkgsrc, to be able
to type

  # update-packages

perhaps answer a question about which branch to go to, and then have
the right thing happen (all packages updated, with renamed packages
tracked to the new ones) with no thought and no more questions.

When that works, then I think it's reasonable to muck with categories
more lightly.


Do we really think people are having less fulfilling lives or more
trouble because it's hard to find out the list of vc-relevant stuff in
pkgsrc?  For me, I ask people or google to find tools that might do
what I want, and then see if they are in pkgsrc.  And there will
always be multiple ways to organize things, so the notion of a single
primary key will be inadequate, and thus I think we'd be better off
with better search/metadata tools than recategorizing.

All that said, the idea of a vc category has some appeal, since it is
clearly a 'primary key', but I still think the pain of renaming is too
great compared to the benefit.

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

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

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

iD8DBQFEuXo++vesoDJhHiURAkxjAJwJzb5tRoBanUEBHalppeCEaTwAzACgq6D9
EeVmqMfc89enU+E0QNF/pZY=
=ZvJV
-----END PGP SIGNATURE-----
--=-=-=--