--- Begin Message ---
Recently many packages have been renamed so that they match the upstream
name. This is good for the long term, but causes considerable grief in
updating. I'll use (GConf2)devel/GConf2 -> (Gconf)devel/GConf as an
example.
Specifically:
1) make replace fails for renamed packages. This is perhaps not so hard
to fix; it will need to take an explicit "old package" name from which
to save dependencies and to delete, so that we can do
make replace OLDPKGNAME=Gconf2
I think that the new package having a different PKGNAME is not a
problem, but I'm not sure. pkg_add -u needs support for this too.
2) pkg_rolling-replace will extract PKGPATH, and then notice that the
directory is missing.
So, I'd like us to design (quickly) a database (file format) to store
the information usable for pkg_rolling-replace, and maybe automatically
usable by make replace. I'll assume that something like (1) is done.
Concentrating on semantics, the primary use case for the database is
There is an installed package PKGNAME name1 with PKGPATH path1.
In pkgsrc path1 has been moved to path2. name2 may or may not equal
name1.
Some tool (or human) wants to update packages, and name1 appears out
of date because path1 can't be found, or doesn't match.
In this case the right thing is
"cd path2 && make replace OLDPKGNAME=name2"
or the equivalent "pkg_add -u".
There's another aspect, which is packages that are removed and there's
an alternate suggestion. I am leaving that out because it requires
human judgemnt, as opposed to being mechanical - Gconf's renaming isn't
cause to ask an admin if they want to install the 'new' version any more
than a regular update.
This is complicated by the fact that multiple renames will happen over
time. I am only trying to handle the most recent rename, and renames
really should be rare - if we are renaming any particular package more
than once every two years something is seriously wrong. For example,
the current gnome rename binge is due to the gnome1->2 transition, and
that was a long long time ago. So automatically handling only the most
recent rename seems fine, with human intervention required for harder
cases.
So, I propose the following text file
RENAMEDATE OLDNAME OLDPATH NEWNAME NEWPATH
with date in YYYYMMDD, *NAME being PKGNAME (no version) and *PATH being
PKG_PATH (e.g. "devel/GConf", no quotes). Entries are required to be
sorted, and usage would use the latest matching one. We can maybe
remove entries older than 2 years - doing a piecewise update for more
than that is really hard - 1 year is merely painful, although this would
fix a lot.
I don't think we can get this from doc/CHANGES in a reasonable way.
Perhaps this can be doc/RENAMES.
We would only put in entries when it is intended that a package
installed from OLDPATH should be replaced by NEWPATH. When we do
something like
import guile as guile16
rename guile18 to guile
We'd have a rename
20070921 guile18 lang/guile18 guile lang/guile
but no entry for guile16; the act of renaming indicates that the
standard upgrade path is to guile16.
Usage, for pkg_rolling-replace, would be to first see if the old
PKG_PATH is present. If so, see if PKGNAME from the current version of
that dir is present. If it is, just make replace. If not, look for an
entry with OLDPATH and NEWPATH both equal to PKG_PATH, NEWNAME equal to
the new PKGNAME, and then look for a package OLDNAME, and if found make
replace OLD_PKGNAME=OLDNAME.
If the old PKG_PATH is not present, then look for a OLDNAME OLDPATH
entry and use the new values.
Do people think this would work? Comments? Objections?
I've been talking about this for a long time, but I think it will be
easier to implement this than struggle with gome updates on multiple
systems.
--- End Message ---