tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD's sed is not gsed (Was: Re: pkg/45752: security/gnome-keyring does (still) not build)
On Sat, 31 Dec 2011, David Holland wrote:
> 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.
>
> [....]
>
> 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.
I agree with this idea, it makes sense.
>
> 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.
gsed? what about textproc/nbsed, it's already a built-in to the bootstrap
script and mk/tools/replace.mk, only needs removing 5 lines from various
mk/tools/tools.${OPSYS}.mk and are already be a part of the bootstrap-kit
on those platforms that need it.
> The catch, which is probably fatal, is that one of these is
> bootstrap-mk-files. Anyone have a better idea?
Not if textproc/nbsed is used.
--
Steven
Home |
Main Index |
Thread Index |
Old Index