Opened 20 years ago

Closed 15 years ago

Last modified 11 years ago

#2377 closed defect (fixed)

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: cooljeanius (Eric Gallager)
Port:

Description (last modified by ryandesign (Ryan Carsten Schmidt))

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 (9)

comment:1 Changed 18 years ago by markd@…

Type: defectenhancement

comment:2 Changed 18 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.

comment:3 Changed 17 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.

comment:4 Changed 17 years ago by nox@…

Milestone: MacPorts base bugs
Priority: ExpectedNormal
Type: enhancementdefect
Version: 1.0

comment:5 Changed 16 years ago by tobypeterson

Milestone: MacPorts base bugsMacPorts Future

Milestone MacPorts base bugs deleted

comment:6 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Description: modified (diff)

This problem prevents a workaround to #17452.

comment:7 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)

comment:8 Changed 15 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 1.9.0
Resolution: fixed
Status: newclosed

comment:9 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

Note: See TracTickets for help on using tickets.