Opened 16 years ago

Closed 15 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

My only thought is that this could be related to #12013 but I haven't yet tested if undoing r36762 fixes it.

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

Summary: port deactivates then activates active dependency if another version is installedport 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 in reply to:  2 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 15 years ago by ryandesign (Ryan Carsten Schmidt)

Milestone: MacPorts base bugsMacPorts 1.7.0

comment:6 Changed 15 years ago by blb@…

Milestone: MacPorts 1.7.0MacPorts 1.7.1

comment:7 Changed 15 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 15 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:9 Changed 15 years ago by jmroot (Joshua Root)

Fixed for trunk in r47771.

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

Resolution: fixed
Status: newclosed

Backported to 1.7 branch in r47773.

Note: See TracTickets for help on using tickets.