At Fri, 28 Oct 2005 15:00:52 -0400 (Eastern Daylight Time),
Todd Vierling wrote:
> 
> On Fri, 28 Oct 2005, Greg A. Woods wrote:
> >
> > That should be a very strong hint to everyone that there's something
> > fundamentally wrong with the idea of forcing all the users of a shared
> > Makefile.common to have their own unique PKGREVISION setting.
> 
> No, that is by design.

What I meant to say more clearly is that the design is broken, or at
least flawed in some way.  :-)

The fact that tools are needed to deal with such a very simple concept
is yet another very strong hint that the design is even more flawed.

> Actually, a very common bump of packages of this type comes from dependency
> ABI changes, which usually affects only one of the Makefile.common-using
> packages, not all of them.  Last I checked, when I swept out the
> common-based PKGREVISION, at least three fourths of the PKGREVISIONs were
> divergent among such packages.

I don't dispute your numbers -- I'm just observing that there's
obviously some kind of fundamental problem with this rule when it keeps
getting re-broken, and even more of a problem when tools are needed to
manage the result.

It would still be interesting to know for certain why they all diverge
and whether or not they all should have diverged, though that may be a
fairly detailed study to take on.

At the same time I don't really know though what the answer is to the
problem I'm trying to point out.

I would have thought it should be quite obvious to even a naive
developer that putting a PKGREVISION setting in a file named
Makefile.common would mean that it would likely affect several packages,
and perhaps it is and perhaps that's the problem.

I'm guessing this only ever causes a problem when the Makefile.common is
bumped, for good cause, and then some other package that uses it also
has to be bumped though there's no need to bump all its sibling packages
at the same time.

So, how common is the case where the common-based sibling packages all
bump their PKGREVISIONS at the same time?  I.e. is there any
justification for having both a way to bump the group as well as a way
to bump the members individually?

Could such a mechanism be sanely based on a simplistic "increment"
mechanism as others have suggested?  Does that actually quantifiably
complicate things more than just having two separate variables?  Are
both of these ideas quantifiably more or less burdensome than using the
external tools you've mentioned to make common changes in such packages?

Maybe "make" needs a simple integer increment operator!  :-)

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>