Opened 14 years ago

Closed 13 years ago

#25401 closed defect (wontfix)

replaced ports are not deactivated automatically when the first conflict detected is with a directory

Reported by: vinc17@… Owned by: macports-tickets@…
Priority: High Milestone:
Component: base Version: 1.9.1
Keywords: Cc: anddam (Andrea D'Amore)
Port:

Description (last modified by anddam (Andrea D'Amore))

When trying to upgrade py25-numpy:

--->  Computing dependencies for py25-nose..
--->  Dependencies to be installed: py25-distribute 
--->  Activating py25-distribute @0.6.13_0
Error: Target org.macports.activate returned: Image error:
/opt/local/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg-info already
exists and does not belong to a registered port.  Unable to activate port
py25-distribute. Use 'port -f activate py25-distribute' to force the activation.
Log for py25-distribute is at:
/opt/local/var/macports/logs/_Users_vinc17_software_dports_python_py25-distribute/main.log 
Error: The following dependencies failed to build: py25-distribute
Error: Unable to upgrade port: 1

However /opt/local/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg-info has files that belong to py25-setuptools:

$ port contents py25-setuptools | grep
/opt/local/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg-info
  /opt/local/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg-info/PKG-
  /INFO
  /opt/local/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg-info/
  /SOURCES.txt
  /opt/local/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg-info/
  /dependency_links.txt
  /opt/local/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg-info/
  /entry_points.txt
  /opt/local/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg-info/
  /top_level.txt
  /opt/local/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg-info/zip-
  /safe

and all the files in /opt/local/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg-info belong to py25-setuptools.

So either there should be no errors or the activation of py25-distribute tries to remove files from py25-setuptools, contrary to what the message says, and using -f as suggested may break the installation!

Change History (8)

comment:1 Changed 14 years ago by vinc17@…

Note: doing

sudo port -v upgrade py25-setuptools

first solved the problem (py25-setuptools is replaced by py25-distribute). Still, the MacPorts logic concerning file owner detection is broken.

BTW, I wonder why the dependency rules didn't automatically replaced py25-setuptools by py25-distribute.

comment:2 Changed 13 years ago by anddam (Andrea D'Amore)

Cc: and.damore@… added

Cc Me!

comment:3 Changed 13 years ago by anddam (Andrea D'Amore)

Description: modified (diff)
Owner: changed from macports-tickets@… to and.damore@…
Status: newassigned

It seems that mp thought py25-setuptools was not installed.

It has been 5 months since you open the ticket so maybe you've changed your setup, is the tickes still up to date? i.e. can you reproduce the issue?

I wrapped description at 80 columns.

comment:4 Changed 13 years ago by anddam (Andrea D'Amore)

Owner: changed from and.damore@… to macports-tickets@…
Status: assignednew

comment:5 in reply to:  3 Changed 13 years ago by vinc17@…

Replying to and.damore@…:

It has been 5 months since you open the ticket so maybe you've changed your setup, is the tickes still up to date? i.e. can you reproduce the issue?

I solved the problem by doing

sudo port -v upgrade py25-setuptools

But this is the kind of thing that MacPorts should do automatically via dependencies.

comment:6 Changed 13 years ago by jmroot (Joshua Root)

The error message is actually correct; directories are not registered to any port.

comment:7 Changed 13 years ago by anddam (Andrea D'Amore)

Description: modified (diff)

I broke EOL while reformatting long lines, fixed.

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

Resolution: wontfix
Status: newclosed
Summary: Incorrect error ".../setuptools-0.6c11-py2.5.egg-info already exists and does not belong to a registered port"replaced ports are not deactivated automatically when the first conflict detected is with a directory

This is a pretty rare case that would require a highly disruptive fix. Not going to happen unless someone does the work and provides a patch.

Note: See TracTickets for help on using tickets.