Re: pkgin, version numbers and upgrade policy

["Ian D. Leroux" <idleroux%fastmail.fm@localhost>]

On Mon, Aug 29, 2016, at 09:20, Thomas Klausner wrote:
> On Mon, Aug 29, 2016 at 11:16:25AM +0200, Havard Eidnes wrote:
> > I've noticed that we have a more or less common routine that when
> > significant changes are made to a package, so-called "recursive
> > PKGREVISION bumps" are done.  If I understand correctly, this is
> > primarily done so that users of binary packages will notice that
> > there's a need to also update dependent packages, and to trigger an
> > upgrade, typically via pkgin.
>
> The point mostly is that we want to have different names for binary
> packages that have different contents.

A more basic point is that reinstalling a binary package is
fundamentally different from rebuilding a (source) package.  When you
make update or pkg_rolling-replace, all the dependent packages are
re*built*, resulting in new packages with contents different from the
ones you had before (in particular, they are buildlinked against the
currently available version of their dependencies).  Whereas when you
reinstall a binary package you should be getting exactly the same files
you got before, those that were contained in the tarball.  It's only
useful for pkgin to update a binary package if a new version with
different
contents has become available, and the only way for pkgin to know that a
new version is available is the version information in the package name.
In this sense, the fact that it's possible to have binary packages with
different contents but the same filename is plausibly a bug.

That said, tools to automate error-prone maintenance tasks usually sound
like a good idea to me...

-- IDL