Flavors: How to preserve specific optionality in pkgsrc builds? about pkgin

[Kerrnel]

Thanks for your (very quick) help - changed to https://pkgsrc.smartos.org/packages/NetBSD/trunk/x86_64/All in /usr/pkg/etc/repositiories.conf and after upgrade - ldap is indeed enabled.

(I wasn't trying to be a snob with just the NetBSD.org repot - if I had read more, I'd have stumbled upon using smartos. Thanks for your contributions! Been using src via pkgsrc for 25 years - I guess prebuilts time has arrived ;) ... Perhaps if anything a choice on first run from a list of repot / benefits would be a nifty addition.)

[jperkin]

Which repository is this? Both the macOS and illumos package sets enable the ldap option by default.

[Kerrnel]

NetBSD (10rc6)

[jperkin]

Ok, and are these packages from pkgsrc.smartos.org or from NetBSD?

[Kerrnel]

https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/10.0/All

$ pkgin pkg-build-defs cyrus-saslauthd
Information for https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/10.0/All/cyrus-saslauthd-2.1.28nb2.tgz:
Build information:
CONFIGURE_ARGS=--with-configdir=/usr/pkg/etc/sasl2 --with-plugindir=/usr/pkg/lib/sasl2 --disable-java --disable-anon --disable-checkapop --disable-cram --disable-scram --disable-digest --disable-gssapi --disable-krb4 --disable-ldapdb --disable-login --disable-ntlm --disable-otp --disable-passdss --disable-plain --disable-sql --disable-srp --disable-srp-setpass --with-dblib=none --without-openssl --without-pam --without-saslauthd --sysconfdir=/usr/pkg/etc/sasl2 --with-saslauthd=/var/run/saslauthd --with-openssl=/usr --without-pam --without-ldap --disable-gssapi --prefix=/usr/pkg --build=x86_64--netbsd --host=x86_64--netbsd --mandir=/usr/pkg/man --enable-option-checking=yes

$ saslauthd -v
saslauthd 2.1.28
authentication mechanisms: getpwent rimap

[jperkin]

Ok, yeh, the NetBSD builds are always done with default options, and there's no point asking them to change that. The packages I provide from pkgsrc.smartos.org including the NetBSD ones have lots of options enabled including ldap (because I believe they are more useful to more people that way).

If it's possible to provide separate modules as different packages then yes that's the best way to do this, we do that where possible.

In terms of how pkgin handles this, everything is keyed on PKGPATH, so if you want to provide your own build of this package then it needs to be done in a different source path, for example local/cyrus-saslauthd, and then pkgin will consider yours only and not try to overwrite it with security/cyrus-saslauthd from the main repository.

Hope that helps.