Discouraging variants [was: Re: port install efficiency issue]

[Rainer Müller]

Shreevatsa R wrote:
>> 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.

Breaking ports can always happen. Why would this be different when there
are less or no variants?

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

You don't need to test each and every variant combination. In most cases
it is safe to assume that if +foo +bar works, also +foo and +bar as
single selected variants work.

> 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], [...]

It is the responsibility of the maintainer to select what is included by
default without variants, in default_variants or additionally available
as variant.

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

What I learnt mostly is that Mac users are ignorant people who like to
complain and rant if software does not work. But the number of people
actually filing tickets and providing patches is small.

> 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? :)),

Think of ports requiring a TeX distribution to build their docs.

> in which
> case make it a separate port. 

So you say maintaining multiple ports is easier than maintaining
variants? Keep in mind that for updates you would have to update the
version and checksums in two ports. Also take care that they are using
the same dist_subdir, as the docs are usually distributed in the same
tarball and you don't want to download it twice. Which most probably
makes the port for docs a clone of the original port - except
build.target and destroot.target.

> There shouldn't be "no_docs" variants:
> no one really *needs* not to install docs.

Why should I install docs for a library if I am not going to develop for it?

In an ideal world, there wouldn't be any +no_* variants. That's just a
lame workaround for broken default_variants and negative variant selections.

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

And then I have to select the heavy version requiring >16 other
libraries just because I need support for one of them? Doesn't sound any
better.

Rainer