On Wed, Mar 25, 2009 at 12:51 AM, Ryan Schmidt <[email protected]> wrote: > > On Mar 24, 2009, at 23:05, Shreevatsa R wrote: > >> This would be a good starting point to mention my pet peeve with >> MacPorts, which is the excessive use of variants. >> >> Ideally, all ports would enable by default all the features that users >> might want, and only leave as variants those features which are >> *definitely* undesirable to significantly many people (and definitely >> desirable for significantly many). Instead, some ports try to make >> every feature a separate variant. This is entirely unnecessary: disk >> space is cheap and shouldn't be considered a cost of enabling the >> feature by default. >> >> It is important to remember that with N variants, there are 2^N >> potential versions to test -- such combinatorial explosion is hard to >> maintain and introduces many bugs. There will be situations where >> variants are absolutely necessary, but if there can be consensus >> against variants, and if the Guide (etc.) could suggest to maintainers >> that variants should only be used when necessary, I hope it will lead >> to some improvement. > > I am constantly telling people on the mailing list to use variant sparingly, > only when absolutely necessary. > > Variants frequently don't get tested when ports are updated, so things break > without the maintainer realizing it.
Exactly! I am glad there is some consensus on this point, although some people still disagree. > Are there any specific ports you can point out that have more variants than > you think they need? Well my hope was to influence policy, and didn't particularly want to point fingers -- after all, maintainers providing variants do so in the belief that they are helping the users by "giving them more options". :-) Still, just as an indication of the current state of variants, I compiled a list: after ignoring platform variants and "universal", there are 130 ports with at least 4 variants: that's already 16 configurations (ignoring conflicts etc.), which is more than most maintainers have time to test. See http://web.mit.edu/vatsa/Public/macports-var/variants-04.txt (or see http://web.mit.edu/vatsa/Public/macports-var/ for the ~400 ports with at least two variants, etc. There are a dozen ports with *16* or more variants. In some cases all of them can be justified, but in many others it is hard to imagine someone who would want one subset of the features and be actively harmed by the rest.) The broader point is here that a package maintainer is *not* doing the user a service by providing a lot of options. It is very frustrating to install something, find out later that there's some feature missing, and have to install again with a different variant. It is also frustrating to have to always check variants first before installing (not only of what one is installing, but also of its dependencies), or maintain one's own "variants.conf" (or "USE flags" or whatever arbitrary configuration mechanism). More generally, it is the packager's *job* to make choices for the user[1]; not doing so is just evading responsibility. Simply throwing every possible option as a variant, just because one couldn't decide if someone would *not* want it or not, simply increases the chances of failure[2], and is not pleasant to anyone, especially Mac users accustomed to encountering decisions Done Right. Having to pick from so many choices feels awful[3,4]. Just design for yourself[5], and if there are disgruntled users they'll let you know. There, I'm off my soapbox. Really, just please read [1]. Back to MacPorts specifically, a few humble suggestions: always install docs unless there is a big dependency like Doxygen (also worth considering: is doxygen *really* a very big dependency? :)), in which case make it a separate port. There shouldn't be "no_docs" variants: no one really *needs* not to install docs. More generally, install all features wherever possible (e.g. why is mp_completion a variant for zsh instead of being installed by default? Just a random example from the bottom of the list, not complaining about that port specifically) and where there are cases where this is really "too" huge (say, wrt build time, not disk space), have just one variant, between a sensible "light" version and the "heavy" version. Bug #126 still needs to be fixed, but maybe it can be made less important. ;-) Regards, Shreevatsa [1]: http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html [2]: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html [3]: http://www.columbia.edu/~ss957/articles/Choice_is_Demotivating.pdf [4]: http://www.amazon.com/dp/0060005688 [5]: http://www.37signals.com/svn/posts/904-why-we-disagree-with-don-norman _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
