New Ticket     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #2377 (closed defect: fixed)

Opened 8 years ago

Last modified 2 years ago

portvariants doesn't reflect excluded variants

Reported by: david.serpa@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.9.0
Component: base Version:
Keywords: Cc:
Port:

Description (last modified by ryandesign@…) (diff)

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}"
                        }
                }
        }

Change History

Changed 6 years ago by markd@…

  • type changed from defect to enhancement

Changed 5 years ago by 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.

Changed 5 years ago by 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.

Changed 5 years ago by nox@…

  • priority changed from Expected to Normal
  • version 1.0 deleted
  • type changed from enhancement to defect
  • milestone set to MacPorts base bugs

Changed 3 years ago by toby@…

  • milestone changed from MacPorts base bugs to MacPorts Future

Milestone MacPorts base bugs deleted

Changed 3 years ago by mcalhoun@…

  • description modified (diff)

This problem prevents a workaround to #17452.

Changed 3 years ago by ryandesign@…

  • description modified (diff)

Changed 2 years ago by jmr@…

  • status changed from new to closed
  • resolution set to fixed
  • milestone changed from MacPorts Future to MacPorts 1.9.0
Note: See TracTickets for help on using tickets.