Re: multiple version of packages with the same PKGBASE

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

> Another comment I have ... is that colon-delimited two-part style of:
>       package name with dewey comparison:../../path/to/package

> is not also used in pkg_summary(5) data.

> Of course, we can parse it.

> But we may have packages that are renamed or moved multiple times. So 
> having an OVERRIDES (or SUPERSEDES) with multiple entries -- each two 
> parts -- becomes more confusing.

> That is why I suggested two parts (which match up with pkg_summary(5)'s 
> PKGNAME and PKGPATH):

> PREV_PKGNAME
> previous package name or multiple package names

> PREV_PKGBASE
  ^^^^^^^^^^^^
  PREV_PKGPATH?

> previous PKGPATH or multiple package paths
PREV_PKGNAME is good enough for binary upgrades.
But I think PREV_PKGPATH is not enough for source-based upgrades.
See below.

> (I also suggested PREV_PKGBASE instead of PREV_PKGNAME before, but 
> PREV_PKGNAME is better since will include dewey comparison like 
> pkg_summary(5) DEPENDS format.)
PREV_PKGBASE with version stripped is definitely not enough.

Suppose glib3 appears that is not compatible with glib2.
So, you rename glib package to glib2 and create new package glib which
is actually glib3.
Then:
    devel/glib2/Makefile:
          PREV_PKGBASE+= glib
    devel/glib/Makefile:
          # no PREV_PKGBASE here

glib2 and glib (glib3) cannot coesist because glib2 "supersedes" glib.

This why I included version REGIONS in my examples.
They are important.

The same for PREV_PKGPATH. Without version included we have the
exactly same type of unresolvable conflicts, but for PKGPATH.

I don't think specifying versions twice (once for PREV_PKGNAME and
once for PREV_PKGPATH) is good idea. So, single variable SUPERSEDES
looks better for me.

-- 
Best regards, Aleksey Cheusov.