"Jeremy C. Reed" <reed@reedmedia.net> writes:

> On Fri, 21 Sep 2007, Geert Hendrickx wrote:
>
>> But what with packages that have a differrent API or datafile format in
>> newer versions?  E.g. if apache-1.3.x or PostgreSQL 7.x get's EOL'd, I'd
>> vastly prefer my update script to error out than to blindly update it to
>> the latest version.
>
> That was sort of my point in the other thread about apache naming. I don't 
> want my binary-only upgrade to blindly update from apache to apache to 
> apache (I purposely leave out versions there as the package names 
> themselves are currently the same.)
>
> So now I can just check if PKGPATH is different and then error out.

And you could still do that, because I am not suggesting rename entries
to cause upgrades across major versions.  An upgrade tool has to find
PKG_PATH from the installed package, I think, unless we have some far
hairer database.  I suppose that's where a pkgid would come in.

To meet your needs, programs that are incompatible have to have
different PKG_PATHS and more or less stay that way.  Essentially, only
have fooN in pkgsrc, and not foo, and don't rename.

I would like to address the 'package dir has been renamed, maybe with
package name also, and there's nothing else complex going on" problem.
Whether and how apache13 gets updated to apache2 is really not part of
this.

Do you really think that these two issues need to be addressed at the
same time?  Do you think that my proposal will make the cross-major
upgrade problem worse?