revbumps and version sharing

[Robert Elz <kre%munnari.OZ.AU@localhost>]

Today I almost experienced a poor side effect if the way pkgsrc
handles shared version numbers and revbumps.

Policy is (and correctly, I think) that if a package that gets
its version number from another package (version number sharing)
needs a revbump, then the PKGREVISION is not to be shared, and
goes in the Makefile for the package that needs the revbump.

However, what that can cause is what almost happened today (and might
have happened to some people).

That is, sysutils/cdrdao was changed from 1.2.2 to 1.2.3.

sysutils/gcdmaster gets its version from sysutils/cdrdao
(they share the same version number).   That's all fine, when
cdrdao was updated, gcdmaster's update just followed along,
and if all had been well without any other effort.

Fortunately, gcdmaster broke its PLIST because of the cdrdao
update, and needed to be fixed (which has happened, there's
no bug left to correct).   I say "fortunately" as at version 1.2.2
gcdmaster had been at PKGREVISION=6 (6 revbumps) - when cdrdao
was updated, from 1.2.2 (naybe 1.2.2nbN for some N, that
doesn't matetr) to 1.2.3, gcdmaster was effectively updated
from 1.2.2nb6 to 1.2.3nb6 - the version from cdrdao was
updated, and, as gcdmaster wasn't touched, its PGKREVISION
wasn't touched either.

Later, gcdmaster was corrected, and its PKGREVISION (which,
as after all version updates, is no longer needed) was removed.

Had the 1.2.3nb6 version built correctly however (and it would
have at least seemed to build correctly for anyone without PKG_DEVELOPER=yes)
then I'd have a version of it built that's newer than the pkgsrc
version (1.2.3nb6 has to be better than 1.2.3, right?) and I
most likely wouldn't be updating for the next several revbumps of
gcdmaster, always believing that I already had a newer one.

One way to fix that would be to require than anyone updating
a package, whose version is shared by others, also go remove
the PKGREVISION from all the other packages.   That would work,
in theory - in practice, probably not, aside from not necessarily
knowing that the version number is shared, the work to go
find all the packages that are sharing the version number
is likely to me enough that developers will just conveniently "forget"
to do it (just an honest mistake, I'm sure).

So, that's not reasonable - it needs to be automated, so I'm
going to sugegst a policy for handling revbumps of packages that
obtain their version indeitity from another package (like gcdmaster,
but there are quite a few).

That is, whenever a PKGREVISION is added to such a package
(they're obvious in their Makefiles - the PKGNAME or similar
always include's some other package's version number name)
the PKGREVISION should be protected by a test that checks
that the base version remains the same as it was when the
PKGREVISION was added.

For a concrete example, if gcdmaster had, rather than just

        PKGREVISION=6

instead included

        .if !empty(${CDRDAO_VER:M1.2.2})
        PKGREVISION=6
        .endif

then when CDRDAO_VER changed from 1.2.2 into 1.2.3 the
PKGREVISION would simply be gone (effectively).   The next
time the package Makefile was updated, the whole stanza would
just be removed (until a similar one, but referring to 1.2.3,
or whatever cdrdao version was then current) was neeeded for
a future revbump.

The one hassle I see with this, are the automated revbumps that
pkgtools/revbump manages (the "find every package that depends
upon this one, and revbump it" stuff) - I suspect that it could
be taught to look for the right kind of pattern and automatically
extract the version name variable (adding the .if is easy if we
know what name to test for, and which package it comes from)

If automating that with cirrent pkgsrc Makefiles looks too hard,
we could provide assistance (a one time sweep of the Makefiles,
with a one line addidion to relevant ones), in the form of a new
make veriable, intended to be used by nothing but pkgtools/revbump
which would be something like

        BORROWED_VERSION=CDRDAO_VER:1.2.2

which just says what variable and value the package currently
expects, or perhaps

        BORROWED_VERSION=CDRDAO_VER:../../sysutils/cdrdao

which gives the var name, and which package to look for it in,
then a 
        make V=CDRDAO_VERS show-var
in ../../sysutils/cdrdao would supply the appropriate version.

Auto revbumps, and major version changes, are independent events,
so pkgtools/revbump wouldn't need to handle the case where
CDRDAO_VER changed, if PKGREVISION is already in gcdmaster's
Makefile, assume it is done correctly, if it needed to be added,
then we can easily get cdrdao's current version number to
encode into the .if it would need to add when it also adds the
PKGREVISION line -- we know from the presence of this BORROWED_VERSION
in the Makefile that the .if is required.

Opinions?

kre