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

[Emmanuel Hainry]

Citando Shreevatsa R :
> 
> On Wed, Mar 25, 2009 at 12:51 AM, Ryan Schmidt <ryandesign at macports.org> 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.
> 
> > 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.


More often than not, if the port compiles with all the variants turned
on, then everything will be OK. I happen to have tested most
combinations of variants for mpd (before I had a comaintainer who added
even more variants) and testing a few combinations enabling or disabling
some variants is far more easy than testing that it compiles on all
architectures and all systems "supported" by macports.

As I now don't have a macosx computer, some ports simply don't compile
as they are mac centric. If a dependency is not absolutely necessary, I
am happy to be able to disable it (for example making moreutils compile
with docs was a real pain when I first made the port, simply does not
work now that I don't have one).


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

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

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

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.


Best,
milosh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090326/4fe9af22/attachment.bin>