jonesc at hep.phy.cam.ac.uk
Tue Apr 12 13:08:26 PDT 2016
> On 12 Apr 2016, at 8:50 pm, Daniel J. Luke <dluke at geeklair.net> wrote:
> 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
thats a matter of opinion.
As far as ROOT is concerned if a user wants a custom option, they are expected to know why, and what that entails. I do not view that as user hostile, just expecting the user to have some idea as to what they want and what that means. If they don’ t wh=ant to do that by hand use macports variants (see below).
>>> 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.
No, it is very different.
reinstalling with a new set of variants is a lot easier than figuring but by hand what options need to be specified to achieve that, and what other dependencies are required. MP, handles all that just fine.
Reinstalling with new variants is, as far as I am concerned, not a major issue.
> 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).
Variants aint going away any time soon, as far as I am concerned.
> Daniel J. Luke
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1910 bytes
Desc: not available
More information about the macports-dev