Re: multiple version of packages with the same PKGBASE

["Jeremy C. Reed" <reed%reedmedia.net@localhost>]

On Thu, 14 Feb 2008, Aleksey Cheusov wrote:

> Examples:
>    1) bzip2 is splitted into two packages: bzip2 and libbzip2.
>       Then 
>  
>       devel/libbzip2/Makefile:
>         OVERRIDES+=      bzip2<=x.y.z:../../archivers/bzip2
> 
>         where x.y.z is a last version of "monolitic" bzip2.
>    2) puthon becomes puthon24, and python25 becomes puthon
> 
>        lang/python24/Makefile:
>         OVERRIDES+=      python>=2.4.0<=2.4.999:../../lang/python
> 
>        lang/python25/Makefile:
>         OVERRIDES+=      python25>=2.5.0<=2.5.999:../../lang/python25
> 
> OVERRIDES may look very similar to CONFLICTS and DEPENDS.


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
previous PKGPATH or multiple package paths

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

These two variables would be defined in respective pkgsrc Makefiles. And 
also the pkg_summary(5) extended for them.

If a tool is searching for a PKGNAME but can't find it, it could next 
search for PREV_PKGNAME to find out new PKGNAME.

Also this would help with conflicts: ignore the CONFLICTS if the 
PREV_PKGNAME had the same PKGBASE as the CONFLICTS.

The PREV_PKGPATH could be used to find moved packages. Maybe that doesn't 
matter.

Or would you like:

SUPERSEDES_PKGNAME
SUPERSEDES_PKGPATH

OVERRIDES_PKGNAME
OVERRIDES_PKGPATH


> But I didn't think over all details. May be I miss (and most probably
> I do) something. Anyway this approach seems to me much better than
> external database.

  Jeremy C. Reed