[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: multiple version of packages with the same PKGBASE
On Thu, 14 Feb 2008, Aleksey Cheusov wrote:
> 1) bzip2 is splitted into two packages: bzip2 and libbzip2.
> 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
> OVERRIDES+= python>=2.4.0<=2.4.999:../../lang/python
> 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):
previous package name or multiple package names
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
Or would you like:
> 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
Main Index |
Thread Index |