Re: multiple version of packages with the same PKGBASE

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

Aleksey Cheusov <cheusov%tut.by@localhost> writes:

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

Perhaps, but that is a proposed change to the current pkgsrc norms.

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

It shows how things are.  It perhaps is not a good argument that the
PKGNAME couldn't be different.

Binary packages contain the PKGPATH.

Asserting that PKGBASE should be enough seems unreasonable (although it
might be true).  To make a valid argument for change, one has to
establish requirements for the operations that need to be done and see
how the proposed new scheme works compared to the current scheme.  I'm
not saying your proposal is bad - it may be that it would work better.
Instead, I'm saying that "x ought not to be required" doesn't hold any
logical weight.

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

One of the current advantages of PKGBASE being the same (in the gqview
case) is automatic CONFLICTS management.  gqview and gqview-devel
conflict because they share PKGBASE=gqview.  It's certainly reasonable
to ask if the benefits of unique PKGBASE outweigh the loss of this, plus
possible other trouble that we don't yet realize.

> Ok. I see. You use PKGBASE+PKGPATH as a package "identifier".

Well, PKGBASE and version identifies an instance of binary package, and
PKGPATH ties that binary package back to the current source tree (or a
newer binary bulk build) and thus a family of packages over time,
leading to a rule about when an update is in order.

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

With the current rules, it is necessary to look at PKGPATH to get what I
consider the right behavior.  If you mean that it would be easier to
change the rules, that's a more complicated judgement because there is a
cost of change.

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

As I see it, the solution to renaming is to have a database that says
"with this old name X, the new package is Y".  I don't see how it's
really all that different with or without PKGPATH.

In the end, I think there has to be a way to look at a binary package
and find the current PKGPATH directory.

> 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

So why is that bad?

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

Using source is a key part of pkgsrc, and any scheme has to work with
both source upgrades and the results of bulk builds.  Certainly there is
work to be done to make it better.

I don't understand why it's such a big deal to want to require PKGNAME
to be unique, instead of taking PKGNAME and PKGPATH from an installed
package to search for the pkgsrc source or pre-built binary package.