Opened 16 years ago
Closed 16 years ago
#16085 closed defect (fixed)
port deactivates then activates active dependency if more than one "latest" version of a port is installed
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | MacPorts 1.7.1 |
Component: | base | Version: | 1.7.0 |
Keywords: | Cc: | jmroot (Joshua Root), blb@… | |
Port: |
Description
I have two versions of glib2 installed -- one universal (active), one non-universal (inactive). When I upgrade a port that depends on glib2 (in this case graphviz-devel) port first deactivates glib2 then reactivates the exact same glib2. It shouldn't do that.
This is with MacPorts trunk @38333 on Mac OS X 10.4.11 Intel with Xcode 2.5.
$ port installed glib2 The following ports are currently installed: glib2 @2.16.5_0 glib2 @2.16.5_0+universal (active) $ port upgrade graphviz-devel ---> Deactivating glib2 @2.16.5_0+universal ---> Activating glib2 @2.16.5_0+universal ---> Fetching graphviz-devel [snip]
Change History (10)
comment:1 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | jmr@… added |
---|
comment:2 follow-up: 4 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Summary: | port deactivates then activates active dependency if another version is installed → port deactivates then activates active dependency if more than one "latest" version of a port is installed |
---|
The problem can also be reproduced even if a port doesn't need upgrading, which at least makes it easy to reproduce and test.
After some testing, it seems that r36762 is indeed implicated, though the behavior before r36762 is hardly better. Consider this set of installed ports:
$ port installed dcraw lcms tiff The following ports are currently installed: dcraw @8.86_2 (active) lcms @1.17_0 lcms @1.17_0+universal (active) tiff @3.8.2_2+macosx tiff @3.8.2_2+macosx+universal (active) $
With trunk @36762:
$ port upgrade dcraw ---> Deactivating lcms @1.17_0+universal ---> Activating lcms @1.17_0+universal ---> Deactivating tiff @3.8.2_2+macosx+universal ---> Activating tiff @3.8.2_2+macosx+universal $
With trunk @36761:
$ port upgrade dcraw ---> Activating lcms @1.17_0+universal Error: Activating lcms @1.17_0 failed: Image error: lcms @1.17_0+universal is already active. $
The code tries to activate the "latest" installed version of a port, and I'm going to go out on a limb and assume that the problem occurs when you have more than one "latest" version installed. In my case, both installed lcms ports are the latest version but they have different variants. And the one that's active is not the first one in the list. See:
$ port deactivate lcms @1.17_0+universal ---> Deactivating lcms @1.17_0+universal $ port activate lcms @1.17_0 ---> Activating lcms @1.17_0 $ port upgrade dcraw ---> Deactivating tiff @3.8.2_2+macosx+universal ---> Activating tiff @3.8.2_2+macosx+universal $
See, now it doesn't complain about lcms anymore, because now the first lcms in the list was already active.
So fix #1 that's needed: if the active port is of the latest version then don't deactivate and activate. Ignore the variants in this comparison.
This leads to quandary #2: if the active version is not the latest, and we do need to deactivate it and activate the latest version, what if there's more than one latest version installed (with different variants)? Which one do we activate? We may want to activate the one with the most similar variants to the currently-active one. Does the code currently do this? I don't know which one it picks. This may be a matter for another ticket, or it may in fact be too special a case to warrant spending a lot of time on, but I wanted to point it out.
comment:3 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
I'm not sure this code, either the old or the new, is properly respecting the epoch either.
comment:4 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to ryandesign@macports.org:
This leads to quandary #2: if the active version is not the latest, and we do need to deactivate it and activate the latest version, what if there's more than one latest version installed (with different variants)? Which one do we activate? We may want to activate the one with the most similar variants to the currently-active one. Does the code currently do this? I don't know which one it picks. This may be a matter for another ticket, or it may in fact be too special a case to warrant spending a lot of time on, but I wanted to point it out.
Here's what currently happens:
$ port installed lcms The following ports are currently installed: lcms @1.16_0 lcms @1.16_0+universal (active) lcms @1.17_0 lcms @1.17_0+universal $ port upgrade dcraw ---> Deactivating lcms @1.16_0+universal ---> Activating lcms @1.17_0+universal $
That's fine: 1.16_0+universal was active and MacPorts deactivated it and activated 1.17_0+universal.
$ port installed lcms The following ports are currently installed: lcms @1.16_0 (active) lcms @1.16_0+universal lcms @1.17_0 lcms @1.17_0+universal $ port upgrade dcraw ---> Deactivating lcms @1.16_0 ---> Activating lcms @1.17_0+universal $
Not fine: 1.16_0 (non-universal) was active but MacPorts still chose to activate 1.17_0+universal even though a non-universal 1.17 was available.
comment:5 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Milestone: | MacPorts base bugs → MacPorts 1.7.0 |
---|
comment:6 Changed 16 years ago by blb@…
Milestone: | MacPorts 1.7.0 → MacPorts 1.7.1 |
---|
comment:7 Changed 16 years ago by blb@…
Cc: | blb@… added |
---|
port should always be preferring the latest it can use, so in the case of
lcms @1.16_0 (active) lcms @1.16_0+universal lcms @1.17_0 lcms @1.17_0+universal
it makes sense to activate 1.17, but what algorithm would be used to choose the one without variants vs. +universal? The one with the fewest?
Also, what about
portname @1.2.3_0+foo portname @1.2.3_0+bar
which should be activated?
comment:8 Changed 16 years ago by jmroot (Joshua Root)
I want to get rid of the "make the latest installed version active" dance altogether. There's no reason we can't just figure out the latest version that's installed and compare that to the version in the tree, without it being active.
I figure we should be using the variants from the active version for the new version anyway, rather than activating an arbitrary newer version and using its variants.
comment:10 Changed 16 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Backported to 1.7 branch in r47773.
My only thought is that this could be related to #12013 but I haven't yet tested if undoing r36762 fixes it.