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/, 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.


Home | Main Index | Thread Index | Old Index