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?

In bootstrap script, need_sed=yes is set and nbsed is used as sed
for platforms with your type (1) sed.
Then, two type of sed is used in pkgsrc now.
And about my suggested style, I did not intend to present right solution.
IT IS THE STYLE.
Currently, it is specially treated with TOOLS_PLATFORM.gsed on NetBSD.
I just said, it should not be done with such style.
--
OBATA Akio / obache%NetBSD.org@localhost