Re: pkg/42704 (Adding support for bmake as a pkgsrc tool (ala gmake))

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

The following reply was made to PR pkg/42704; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/42704 (Adding support for bmake as a pkgsrc tool (ala gmake))
Date: Mon, 09 Mar 2015 02:10:34 +0700

     Date:        Mon, 29 Dec 2014 09:02:49 +0000 (UTC)
     From:        dholland%NetBSD.org@localhost
     Message-ID:  <20141229090250.9156BA65D6%mollari.NetBSD.org@localhost>
 
   | netbsd-4 is EOL for some time and so this issue is no longer relevant.
 
 I disagree with this one - the particular issue that led to the proposed
 change may no longer be relevant, but the underlying problem will always
 be present.
 
 Exactly the same issue could apply today for NetBSD 5, and even perhaps
 for NetBSD 6 - (b)make keeps being upgraded &/or fixed, a developer with
 a new (and/or fixed) version is naturally going to want to use it fully
 (that's why new features are added, and how bugs are found so they can be
 fixed).
 
 Outlawing that for pkgsrc packages would be absurd - but since enhancements
 cannot be retroactively added to a released version (at best they can be,
 sometimes, added into the next point release) as long as the older release
 is to be supported by pkgsrc, that would be the effect - unless, as we do
 for everything else (X libraries, etc, gcc, libtool, iconv, even the pkg tools)
 we allow pkgsrc versions to replace the version that comes native with the
 system.   The one glaring exception to this is (b)make.
 
 Since it is so trivial to allow it, I see no reason not to do so.
 I suspect that the only reason that we don't run across problems with
 this more often, is that very fex pkgsrc packages are actually developed
 on NetBSD.  That's sad - but making it harder cannot help.
 
 kre