Re: multiple version of packages with the same PKGBASE

[Greg Troxel <gdt%ir.bbn.com@localhost>]

Roland Illig <rillig%NetBSD.org@localhost> writes:

> Using PKGPATH to identify the exact package feels like cheating to me,
> especially since it sometimes changes intentionally (gnome2 -> gnome)
> and sometimes it shouldn't change (apache-1.3 vs. apache-2.0). How can
> a binary package manager tell the difference?

It's not cheating - it's simply a question of whether multiple source
packages can generate binaries of the same name, and whether we are able
to build different branches with the same resulting name, or whether we
have a rule against it.  PGKPATH defines where the sources are, and thus
"what a package is" in the deep sense, and PKGBASE defines how it's seen
by the user (not pkgsrc maintainer).  In cases like gqview, the result
is the same, just from a different branch, and I don't think there's
anything fundamental about using PKGPATH from the package vs. being able
to find it by a table from PKGBASE.

Moving either PKGBASE and PKGPATH is already a problem, and will remain
so.  The basic rule is that you find the package source identified by
PKGBASE+PKGPATH (or just PKGBASE).  The complicated rule is that you
consult the renaming database to see if the name/names points to a new
PKGBASE+PKGPATH.  In the gnome case, we had

old:  PKGBASE=GConf2 PKGPATH=devel/GConf2
new:  PKGBASE=GConf  PKGPATH=devel/GConf

In the apache case, we have

PKGBASE=apache          PKGPATH=www/apache
PKGBASE=apache          PKGPATH=www/apache2
PKGBASE=apache          PKGPATH=www/apache22

and one checks the PKGPATH for updates, thereby staying on the same
branch.  If we had a "PKGBASE must be unique" rule, then we'd have

PKGBASE=apache          PKGPATH=www/apache
PKGBASE=apache2         PKGPATH=www/apache2
PKGBASE=apache22        PKGPATH=www/apache22

and you'd have the same rule, except that you could consult a table to
find PKGPATH instead of reading it from the binary package.

This is why I don't think renaming is an issue, or rather why it's
orthogonal to the "should PKGBASE be unique".[>

The only simplification (other than perhaps less confusion by people who
don't really understand the rules - which is a good thing because the
rules are complicated) is that if PKGBASE is unique then one can
translate PKGBAS to PKGPATH with a table instead of having to pull
PKGPATH from the old binary package.


The really hard question is about simultaneous installation of the
multiple packages.  For that you need different PKGBASE, but you don't
need a rule that PKGBASE can't ever be the same.

So I don't really care if we add a 'unique PKGBASE' rule.  But even if
we do, I think upgrade programs should pull PKGPATH, because I think the
rule won't end up being followed 100%.