Batteries Included Policy

[Rainer Müller]

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).

 > [...]
> I believe that aiming for "batteries included" will significantly  
> reduce the headache and hassle of installing some software and getting  
> on with your work.

I would find it much more important to use the same variant names for
the same dependencies, so one can add them easily in variants.conf.

Unification of variant names would really be helpful. Currently there 
are variants which do the same but are named differently:
   * +gss and +gssapi
   * +openssl and +ssl (and also -no_ssl)
   * +gnutls and +tls
   * +no_x11, +nox11, +nox, +without_x11 (and also -x11)
   * +doc, +docs, +with_docs (and also -without_docs)
   * +without_bdb, +no_bdb

And probably more I missed right now.

Also, I dislike the "no" or "without" prefix in variant names, there is 
the -foo syntax and default_variants for them. Yes, I know that there 
are still issues (deselected variants are re-applied on upgrades), but I 
consider this naming a lazy workaround (on long term).

The same applies to "with" as prefix for variants, it is redundant or 
even confusing when deselecting this variant (-with_docs would be read 
as "without with docs").

If variant names would follow a clear scheme, it would make it easier to 
add the variants you need to variants.conf and automatically get the 
features you want.

If we solved these issues, we could provide default variant sets for 
server admins and desktop end-users. Either in the guide or as example 
config files for variants.conf. This way everybody could get the 
benefits from variants and also get reasonable default installs with the 
features they need.

Rainer