Citando Shreevatsa R : > > On Wed, Mar 25, 2009 at 12:51 AM, Ryan Schmidt <ryandes...@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
signature.asc
Description: Digital signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
