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

[Shreevatsa R]

Hello,

Firstly, I should clarify that I have/had no intention of starting an
argument; I'm only speaking from a genuine desire to make MacPorts
better.

To reply...

On Thu, Mar 26, 2009 at 09:46:27AM +0100, Emmanuel Hainry wrote:
> Yes, that is what default_variants and negative variants are for. I know
> that the use of default_variants is discouraged, but they are a really
> fine feature of macports. Variants are a great aspect of macports, sure
> there are some bugs with them (126, default_variants not preserved by
> upgrade), sure there are cases of abuse of variants (e.g. mpd, but I am
> proud of it), but don't throw them away or try to reduce their use to
> some really rare use cases unless you want to have 16 ports where you
> had 1 port with 4 variants...

Completely agree that 16 ports is much worse than 1 port with 4 variants.
What is even better is one port with no variants (if possible).

> No one really *needs* not to install docs, but some users (1) really
> cannot install docs when they depend on docbook2X and a strange version
> of docbook-xml-4.5.beta17, when they depend on doxygen. That being said,
> I consider not installing docs a bug in a port.

Great, we agree. :-)
I too agree that ports should install docs by default, and I too agree
that when docbook is a dependency, a variant is justified (under the
present conditions, where docbook takes a long time to install etc.)

On Thu, Mar 26, 2009 at 11:05:06AM +0100, Rainer Muller wrote:
> 
> 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?

When there are more variants, there are more things that can break.
More importantly, things can break *without the maintainer realizing it*
-- a user might install some subset different from what the maintainer
has tested.

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

With enough users, the cases other than the "most cases" occur often
enough; and my point was precisely that maintainers are more likely
to just test +foo +bar and assume that +foo and +bar also work.
(Not saying that they should test all subsets; rather that they
*shouldn't* have to).

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

Agreed.

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

Great. :) So why worry about trying to please the ignorant lazy
complaining ranting people? If they won't even file tickets, you don't
have to work so hard trying to provide so many "options" without even
knowing if there exists someone who cares enough to file a ticket.

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

Good point. You've convinced me; I agree that when there is reason for
not installing documentation by default, it is better to have it as a
variant than as a separate port.

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

Agreed, but we have to work with the world we have. :)
For cases where you feel that no one needs the docs, it would be fine
to remove them entirely: have no variants and don't install docs ever.

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

The question is whether there are users who really want just one
of them. I'm not saying it's possible always, but in most cases, with
a little thought, it is possible to winnow down the possibilities users
*actually* want to a small set.


On Thu, Mar 26, 2009 at 11:32:54AM +0100, afb wrote:
> I thought the whole point of doing Ports for Mac was to provide  
> choice...

IMO, the point was to provide "package mananagement", making it easy to
install, upgrade, and not have to chase down dependencies, especially
for packages without a graphical binary installer.



To reiterate/rephrase, I had two suggestions:

1. That the default selection of variants should be a good choice for
what the user is likely to need, so that he/she won't have to reinstall
with different variants, always be careful to check variants, etc.

2. That there should not be variants corresponding to things no actual
users care about, just to give them "options". This only makes things
worse, so variants should exist only when there is user demand.

It seems everyone agrees with (1), but not everyone with (2).
Most users are only going to be affected by (1), so even just that would
be great.

The arguments for (2) are that
* having too many variants can lead to things break *subtly*
* there is a high cost (to the user) of making "the wrong choice"
* discouraging variants is a way of encouraging maintainers to make the
right choices, as in (1)
* it can reduce the amount of work and testing for the maintainers

Ultimately, of course, the choice of what to do is the maintainers';
since they are the ones doing the work. :)

Cheers,
Shreevatsa