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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev