portvariants doesn't reflect excluded variants

[david.serpa@…]

portvariants always has the form +variant1+variant2+..., never +variant1-variant2-...+... If someone were to exclude one or more default_variants during port install, I think it would be desirable to allow portvariants to take the 2nd form. In base/src, only port1.0/portactivate.tcl, port1.0/ portinstall.tcl and port1.0/portutil.tcl access portvariants. Possible patches for these 3 files follow:

--- darwinports/base/src/port1.0/portactivate.tcl.orig Sun Nov 7 22:03:54 2004 +++ darwinports/base/src/port1.0/portactivate.tcl Sun Nov 7 22:30:57 2004 @@ -54,7 +54,7 @@

# Put together variants in the form +foo+bar for the registry foreach v $vlist {

if { ![string equal $v [option os.platform]] && ![string equal $v [option os.arch]] } {

- set portvariants "${portvariants}+${v}" + set portvariants "${portvariants}$variations(${v})${v}"

}

}

}

--- darwinports/base/src/port1.0/portinstall.tcl.orig Sun Nov 7 22:04:16 2004 +++ darwinports/base/src/port1.0/portinstall.tcl Sun Nov 7 22:31:22 2004 @@ -51,7 +51,7 @@

# Put together variants in the form +foo+bar for the registry foreach v $vlist {

if { ![string equal $v [option os.platform]] && ![string equal $v [option os.arch]] } {

- set portvariants "${portvariants}+${v}" + set portvariants "${portvariants}$variations(${v})${v}"

}

}

}

--- darwinports/base/src/port1.0/portutil.tcl.orig Sun Nov 7 22:04:30 2004 +++ darwinports/base/src/port1.0/portutil.tcl Sun Nov 7 22:31:47 2004 @@ -543,7 +543,7 @@

# Put together variants in the form +foo+bar for the registry foreach v $vlist {

if { ![string equal $v [option os.platform]] && ![string equal $v [option os.arch]] } {

- set portvariants "${portvariants}+${v}" + set portvariants "${portvariants}$variations(${v})${v}"

}

}

}

[gwhitney@…]

There really is a bug here, but not for the reasons originally posted -- the issues that david.serpa raises can cause one's port registry to become corrupt. See Ticket #11920.

[gwhitney@…]

Note ticket #11920 has been resolved, which partially resolves the issues here. The remaining issue is as follows: suppose variants.conf makes the bar variation on by default, i.e. contains a line +bar, but a port is installed with bar explicitly turned off, e.g. port install foo -bar. Then the portvariants string will be empty, since no variants ended up turned on in the install. Then when you do port upgrade foo, the default +bar will apply, and the upgraded version will be installed with the bar variant turned on. However, the usual behavior would be for explicit arguments on the install to be preserved in the upgrade, arguing that the upgrade should occur without the bar variation being turned on.

I don't think this can be fixed by modifying the portvariants string, since I believe you need one place that unambiguously and canonically records what exactly was installed, and portvariants is now being used for that. I think this can only be fixed by separately recording the requested variations or something like that, and using those requests as another layer of fallback arguments (behind explicit command-line arguments but ahead of variants.conf) in the upgrade action. However, finally, I think this should be adjourned until after the Google Summer of Code 2007 activities, since they may affect how variants are encoded, dependencies computed, and upgrade works.