variants

Daniel J. Luke dluke at geeklair.net
Tue Apr 12 12:50:23 PDT 2016


On Apr 12, 2016, at 3:04 PM, Christopher Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>> How do other package managers (that don't have variants) deal with ROOT6?
> 
> I guess they have to decide a set of options that most people want, and just go with that.

and we can't do that?

>> How do users know what functionality they have installed when they install ROOT6 from source?
> 
> If they are installing from source they are expected to know what they are doing, and therefore pick the options they need. They are reasonably well documented.

ok, so it's just actively user-hostile

>> How do users add additional functionality that wasn't built when they first built ROOT6? [the answer is probably 'rebuild’]
> 
> you can’t. Reinstall with the new options.

and again user-hostile

> None of the above changes my opinion on what Macports should do.

the current situation is basically the same as what upstream provides when building from source.

Am I missing somthing? Changing how default variants works only fixes one case:
new install, installing something that depends on a variant of some other port

It breaks existing behavior:
port install A (which installs B as a dependent) is currently the same as port install B && port install A

It doesn't fix things when the dependent is already installed.

This could be fixed by adding variants to the dependency engine OR by making use of the existing dependency engine (ie, breaking the port up into pieces so that things can depend on what they actually need) OR by just getting rid of variants (batteries-included install).

-- 
Daniel J. Luke





More information about the macports-dev mailing list