Batteries Included Policy
Eric Cronin
ecronin at macports.org
Wed Jun 25 14:48:04 PDT 2008
On Jun 21, 2008, at 11:32 PM, Rainer Müller wrote:
> Landon Fuller wrote:
>> I would like to propose a policy for general consideration. I believe
>> it could save everyone energy and brain-cycles; let's call it
>> "batteries included":
>> As a general rule, ports should enable all standard features/
>> functionality that may be useful to an end-user.
>
> Sounds like a good idea, but I am not sure if it is so easy to reduce
> the wide spreaded user base to one single typical end-user.
>
> We already get the usual complaints from users about "Why do I need to
> build $portname, Leopard already has that!!1eleven", so we should
> watch
> not to include big dependencies by default. If the list of
> dependencies
> for a feature is short (and without build time consuming ports), it
> can
> be included by default.
>
>> [...]
>> Features that probably should be enabled by default, but often
>> aren't:
>> - SSL support.
>
> What if a software provides alternatives in using OpenSSL or GnuTLS
> (e.g. curl and wireshark)? I would say we need variants here, but
> one of
> them should be enabled by default.
>
>> - LDAP support.
>
> I doubt the majority of the user base needs this. Personally, I don't
> have OpenLDAP installed and I don't miss anything.
>
>> - Database support (pgsql, mysql, sqlite). The client libraries are
>> cheap to install.
>
> Not that easy, as most ports let you choose the version of the
> library.
> For example there are some ports with +postgresql83/+postgresql82 and
> +mysql4/+mysql5.
>
> Would maybe work fine with postgresql and sqlite, but mysql always
> builds the whole server (see <http://trac.macports.org/ticket/14146>).
>
> I don't think desktop end users deal with databases, but server admins
> do. So I am a bit undecided if this is a good default (see also
> below).
>
>> - SASL/GSSAPI support. Mac OS X is very kerberos-enabled, MacPorts
>> can and should be too.
>
> Kerberos and Cyrus-SASL2 would be installed anyway if we choose to
> make
> LDAP a default. So this is kind of bundled.
>
>
> I may want to add IPv6 to this list. We have some ports using
> --disable-ipv6 by default and adding a +ipv6 variant. I think it is
> reasonable to build everything with IPv6 support these days. An +ipv6
> variant would only be justified if the port provides IPv6 as an
> replacement for IPv4 (yes, I have seen software doing this).
The solution to this which a number of maintainers seem to prefer
(based on pushback I've received when pointing out missing
dependencies in portfiles) is that if LDAP/xSQL/GSSAPI ports are
already installed, take that as an indicator that the user wants that,
otherwise leave it as an option that can be selected and therefore
install the missing dep. This is already happening quite a bit by ./
configure scripts opportunistically enabling external tool linkage
unless the maintainer explicitly takes control... An officially
supported method (detecting and registering undeclared dependencies)
would be a step up from the current situation.
As a security-oriented person, I'm also a bit opposed to throwing in
the kitchen sink by default. In many cases linking against foo at
build time implies enabling foo in the program at run time. For
things like IPv6 (is everyone firewalling the automatic link-local
IPv6 addresses they have when in an all IPv4 environment? writing
their ACLs with IPv6 in mind? When libfoo has a buffer overflow in
parsing input what setuid tools linked against it are now vulnerable
even though you don't use foo in your setup (e.g. insert LDAP for foo
for anyone in a typical 'home user' role).
Thanks,
Eric
More information about the macports-dev
mailing list