tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


"OBATA Akio" <> writes:

> I would like to clean up inet6 option handling.
> First, IPV6_READY, is it still usable?
> Must it be added to BUILD_DEFS for any ipv6 ready packages?
> (It is not documented in the guide, then I feel many packages do not care it)
> Second,  USE_INET6:inet6 is added to  PKG_OPTIONS_LEGACY_VARS in 
> mk/defaults/
> Is it still required?
> USE_INET6 is set as "YES" by default in /usr/share/mk/ for NetBSD,
> so unwanted deprecated variable warning will be risen in any package having 
> inet6 option.
> Furthermore, even inet6 support is experimental, and not in 
> it will be enabled automatically, it is unwished behavior.
> I feel USE_INET6 should be gone away, or opposite behavior, i.e. if 
> inet6 option will be disabled by default.
> Finally, inet6 option in PKG_OPTIONS, even if inet6 option is in 
> I feel it should be removed from PKG_OPTIONS automatically if IPV6_READY=no.
> (but I don't know if there are inet6 options require no system inet6 support 
> or not).

I'm not quite sure what's going on with the existing variables, but I
agree cleanup seems in order.

I would say that in 2012, every program should support IPv6 (or it's a
bug) and so should every OS.  It makes sense to offer a knob the
equivalent of USE_INET6 for packages that could be annoying from trying
to use non-working IPv6 support (even though that situation should be

So, I'd suggest that programs that can have v6 disabled have an inet6
option, default to on if it is thought to work (which is I think what we
have), and then just let people put


in their mk.conf if that's what they want, and drop the USE_INET6 legacy
option support.  As far as I know, we don't have in general have
integration with NetBSD base systems USE_FOO for other FOO

I don't see how IPV6_READY works, from a quick grep in mk/.  Certainly a
package is broken if it fails to autoconf/etc. to decide to compile
IPv6.  Or perhaps it just won't work on systems that are too crufty to
have v6 support - but by now that's really the same thing as "won't work
on systems that are too crufty to have X", for other values of X.
So I would be inclined to just rip out IPV6_READY.

How many people are actually wanting to disable IPv6 support?

Attachment: pgpjAf70f_TRb.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index