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