tech-pkg archive
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index][
Old Index]
Re: multiple version of packages with the same PKGBASE
On 2008年2月14日, 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
Home |
Main Index |
Thread Index |
Old Index