How can variant B imply variant A?

[Jeremy Lavergne]

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)
 * 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)
 * 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

Our chat log is below.

Clemens:  I see the problem with this approach, but consider the case where we'd have this situation multiple times
Clemens: e.g. a port linking glib2 and wxWidgets
Clemens: what do? create four subports?
Jeremy: variants are fine, the issue is automatically changing what one is used… IMO
Clemens: also, the same problem exists when python is built with ucs4; theoretically, we'd have to split each python module installing binaries into a ucs2 and a ucs4 port
Clemens: which brings us to the cross-product of subports issue again
Clemens: python{24,25,26,27}-ucs{2,4}-svn?
Jeremy: yup
Clemens: it's unfortunate, but I see no easy way around it
Jeremy: one tree to rule them all
Clemens: the other possibility would be to tell the user to select the variant
Jeremy: which is what i'm for
Clemens: i.e., abort the build and tell the user: you have glib2-devel, please build with +glib2_devel
Jeremy: rather than "surprise, you're building!"
Clemens: if ppl don't like "surprise, you're building" they should be using -b anyway
Clemens: "surprise, you're building" is the default, b/c users almost never look at licenses or the output of port_binary_distributable
Jeremy: true, but the assumption is a dependency tree doesn't magically change based on a file existing/port being installed
Clemens: that's a strong point
Jeremy: imagine the people who have upgrades all scripted out… they'll be flustered  i'd like to tell them they get that for making assumptions but… people make assumptions
Clemens: altough I still think the users don't care and would just be nagging
Jeremy: users who care would have glib2-devel, no?
Jeremy: users who dont' care would have glib2
Jeremy: my guess, at least.
Jeremy: i wonder if a package somewhere tries to install both currently anyways
Clemens: and the users who have glib2-devel can either be interrupted and asked to specify the variant, or we can just assume they want it by default, if they already have it
Jeremy: well: did they get it because they wanted it?
Clemens: I wonder if there's any users who'd not want +glib2_devel but have glib2-devel installed
Clemens: unless you install bleeding-edge stuff you don't get -devel ports automatically, do you?
Jeremy: in some situations you can
Jeremy: simply because someone wrote a dependency on it
Jeremy: somewhere
Jeremy: also, in PSPP -devel is "current" but not tagged
Jeremy: pspp without -devel is very old
Jeremy: so -devel means various things still, too 
Jeremy: glib2{,-devel} conflict, right?
Clemens: yes
Jeremy: so this would stop the install anyways saying that the dependency couldn't be installed due to a conflict
Clemens: but "CONFLICT!1!!" isn't as helpful as "hey, build with +glib2_devel if you have glib2-devel installed", so printing a message is still a lot better
Jeremy: yea, i'd rather ask them to pick; there are some ports taht explicitly do that
Jeremy: they require a choice in variants
Jeremy: not due to dependencies but because they operate mut ex
Clemens: any examples?
Jeremy: let me grep around… 
Clemens: Yeah, in those cases there's no way to guess what the user probably wants
Clemens: in the case we're discussing there is
Clemens: and I think especially with ports no average user has ever heard of that are only installed as dependency of something it's annoying to have the users select the variant
Clemens: imagine you're installing $random_gtk3_app, which pulls in gtk3, which pulls in gobject-introspection
Jeremy: which is why i suspect the unwitting user being subjected to suddenly building lots of things because we noticed they managed to get glib2-devel might be just as bad
Jeremy: ./databases/dbslayer/Portfile:        return -code error "${name} requires one of these variants: +mysql5, +mysql51, +mysql55, +mariadb or +percona"
Clemens: printing a message and aborting gives the user the feeling of "broken in the dependencies again. why does macports install all this s$%t anyway?", automatically selecting just lets the user continue with what he wanted to do in the first place
Jeremy: ./databases/postgis/Portfile:        error "One of the following variants must be set: [join ${pgsql_ports}]"
Jeremy: true… we're not really interactive to where we can ask for "choose 1 2 or 3"
Clemens: *shrug* I don't think we'll find the ideal solution tonight
Clemens: let's just bounce our thoughts to the list and see what everybody else thinks