How can variant B imply variant A?

Daniel J. Luke dluke at geeklair.net
Tue Aug 21 13:43:47 PDT 2012


On Aug 21, 2012, at 4:26 PM, Jeremy Lavergne <jeremy at lavergne.gotdns.org> wrote:
> Here are our thoughts on the variants, mostly about user assumptions:
> * making subports for every combination of variants is messy (e.g. python{24,25,26,27}-ucs{2,4}-svn)

It is. It would be really nice if we could narrow down the number of supported pythons/perls/etc. so that there was less of this.

> * defaulting to a non-default variant may surprise users by suddenly building packages (e.g. buildbots would never build it/isn't a tested combination across platforms)
> * -devel use is still inconsistent: something else may have non-optional dependency on it (e.g. the user doesn't actually want glib2-devel but doesn't know it's about to get picked)
> * some packages require a choice in variants and don't make any assumptions (e.g. which database to use)

I believe that this is a policy violation (and so a bug with any port that does that). You should get a 'sane' install of some sort whenever you run 'port install foo'

> * users fear/ignore helpful exit messages, assuming they are errors
> * some people have their upgrades scripted out and will be cranky that an assumption wasn't followed by a "smart" portfile


Having the portfiles be as stupid as possible (and as declarative as possible) is good.
--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+





More information about the macports-dev mailing list