Re: NetBSD's sed is not gsed (Was: Re: pkg/45752: security/gnome-keyring does (still) not build)

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Sun, Jan 01, 2012 at 01:57:32AM +0900, OBATA Akio wrote:
 > It means that "NetBSD's sed is compatible with gsed" is not
 > majority in pkgsrc.
 > 
 > Then, if a package does not require gsed on NetBSD, following style
 > should be used instead.
 > 
 > .if ${OPSYS} != "NetBSD"
 > USE_TOOLS+= gsed
 > .endif

I don't think this is the right solution, because it's not just
NetBSD. I think we can be reasonably certain that the native sed is
good enough on any of the BSD platforms, and possibly even on MacOS.
So there are really three cases:

(1) the package needs any sed, and e.g. old SVR4 sed is good eonugh.
(2) the package needs a working sed, which includes the non-gnu native
    sed on a number of platforms (not just NetBSD).
(3) the package specifically needs GNU sed.

Unfortunately, we only have two names to put in USE_TOOLS: "sed" and
"gsed". Therefore, we either need a new name that we'll be able to
remember ("oksed"? "nsed"?) or abandon one of the cases.

I would suggest that we dump case (1). On the legacy platforms
affected most users will want a working sed installed anyway, or so
I'd think, so it's reasonable to install one for building packages.

This would mean:

   - packages that need a working sed should set USE_TOOLS+=sed
   - packages that specifically need GNU sed should set USE_TOOLS+=gsed

This means that 17 packages that currently have "USE_TOOLS+=sed" would
grow a build dependency on gsed on Solaris (and I guess on Irix too if
anyone still cares) and 8 packages would grow a full dependency.

The catch, which is probably fatal, is that one of these is
bootstrap-mk-files. Anyone have a better idea?

-- 
David A. Holland
dholland%netbsd.org@localhost