Re: multiple version of packages with the same PKGBASE

[Aleksey Cheusov <cheusov%tut.by@localhost>]

 >> In pkgsrc there are a number of packages that have the same PKGBASE
 >> but different PKGPATH and versions.  Is it normal?

> Yes, it is normal.  A typical example is graphics/gqview and
> graphics/gqview-devel.  They install the same files, with the same
> names, but from different branches of upstream.
IMHO there should be exactly one instance for describing a package.
And this instance is PKGBASE, of course. PKGPATH is just a way to
minimally _categorize_ them and organize sources in CVS, no more.
Example with graphics/gqview-devel doesn't show anything IMHO because
its PKGNAME can easily be renamed to, say, gqview-devel (from gqview).
In this case binary upgrade will be possible without preserving
information from where this package was built (PKGPATH) and without
additional analisis. PKGBASE should be enough for upgrade.

I don't see any problem in keeping PKGBASE uniq in entire pkgsrc
tree. While not doing this is a bit painful and makes some
restrictions on how upgrades can be done. It also limits me/user to
the current pkgsrc/ structure.  It is not good, but...sometimes it
changes in any case.

> So, this means that if gqview-2.0.4 is installed, with PKGPATH
> graphics/gqview, it's up to date.  Yes, gqview-devel would install
> 2.1.5, but the user hasn't chosen to be on the non-stable branch.
Ok. I see. You use PKGBASE+PKGPATH as a package "identifier".
I propose to use only PKGBASE. Because
1) PKGPATH is necessary only for source-based upgrades.
   For binary upgrades it is easier to not check PKGPATH at all.
   It is possible to check PKGPATH too, I don't see any reason for
   this.

   Renaming packages (glib -> glib1, python -> pythonXX etc.)
   is a very different story and also has EASY solution.

2) It makes easier package manipulation for the third party software.
   One simple example. I recently wrote wip/pkg_online - client/server
   tool that provides
   search capabilities in pkgsrc packages. Central part of it
   is PKGNAME (actually PKGBASE) through which everything is done.
   Suppose I want to see full information about package gqview.
   I do this like the following

     pkg_online_client -i gqview

   Instead of showing me information about ONLY ONE package I query,
   it shows me information about three packages: graphics/gqview-gtk1,
   graphics/gqview, graphics/gqview-devel

> This may be underdocumented, but I think it's pretty sane.
This algorithm is trivial only for those people who name package using
two instances ;) It think single PKGBASE is enough for most cases. The
only reason to use additional PKGPATH is a source-based upgrades.

-- 
Best regards, Aleksey Cheusov.