Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#12107 closed defect (duplicate)

BUG: "port uninstall <portname>" deletes receipt but not files or file map entries when <portname> is specified with case different from the actual case

Reported by: boeyms@… Owned by: jberry@…
Priority: Normal Milestone:
Component: base Version: 1.4.42
Keywords: port filemap case case-sensitivity Cc: jberry@…, boeyms@…, kballard (Lily Ballard)
Port:

Description

As an example, consider the XviD port. "port install xvid" successfully installs the XviD port, although the output of "port installed <portname>" differs slightly depending on the case of <portname>:

Alexandria:~ boeyms$ port installed XviD
The following ports are currently installed:
  XviD @1.1.2_0+darwin_i386 (active)
Alexandria:~ boeyms$ port installed xvid
The following ports are currently installed:
  xvid @1.1.2_0+darwin_i386 (active)

However, the output of "port contents <portname>" differs markedly:

Alexandria:~ boeyms$ port contents XviD
Port XviD contains:
  /opt/local/include/xvid.h
  /opt/local/lib/libxvidcore.4.dylib
  /opt/local/lib/libxvidcore.a
  /opt/local/lib/libxvidcore.so
  /opt/local/lib/libxvidcore.so.4
  /opt/local/share/doc/XviD-1.1.2/AUTHORS
  /opt/local/share/doc/XviD-1.1.2/ChangeLog
  /opt/local/share/doc/XviD-1.1.2/LICENSE
Alexandria:~ boeyms$ port contents xvid
Port xvid does not contain any file or is not active.

After uninstallation, "port installed" behaves as expected:

Alexandria:~ boeyms$ sudo port uninstall xvid
--->  Deactivating xvid 1.1.2_0+darwin_i386
--->  Uninstalling xvid 1.1.2_0+darwin_i386
Alexandria:~ boeyms$ port installed xvid
None of the specified ports are installed.
Alexandria:~ boeyms$ port installed XviD
None of the specified ports are installed.

But "port contents" does not:

Alexandria:~ boeyms$ port contents xvid
Port xvid is not installed.
Alexandria:~ boeyms$ port contents XviD
Port XviD contains:
  /opt/local/include/xvid.h
  /opt/local/lib/libxvidcore.4.dylib
  /opt/local/lib/libxvidcore.a
  /opt/local/lib/libxvidcore.so
  /opt/local/lib/libxvidcore.so.4
  /opt/local/share/doc/XviD-1.1.2/AUTHORS
  /opt/local/share/doc/XviD-1.1.2/ChangeLog
  /opt/local/share/doc/XviD-1.1.2/LICENSE

Furthermore, the files listed in the contents are indeed still on the filesystem:

Alexandria:~ boeyms$ ls /opt/local/include/xvid.h 
/opt/local/include/xvid.h

Unsurprisingly, cleaning and then reinstalling then fails:

Alexandria:~ boeyms$ sudo port clean xvid
--->  Cleaning XviD
Alexandria:~ boeyms$ sudo port install xvid
--->  Fetching XviD
--->  Verifying checksum(s) for XviD
--->  Extracting XviD
--->  Configuring XviD
--->  Building XviD with target all
--->  Staging XviD into destroot
--->  Installing XviD 1.1.2_0+darwin_i386
--->  Activating XviD 1.1.2_0+darwin_i386
Error: Target com.apple.activate returned: Image error: /opt/local/include/xvid.h already exists and does not belong to a registered port.  Unable to activate port XviD.
Warning: the following items did not execute (for XviD): com.apple.activate
Error: Status 1 encountered during processing.

I have encountered exactly the same problem with the docbook2X port, so I do not believe that this is an isolated problem.

I don't how this ought to be fixed, but I did notice two things. The first is that some of the action_* procs in port(1) search the registry for $portname directly, while others search for the return value of "dportsearch $portname no exact"; though the latter returns a list, the first element of the list seems to be the name of the port with the correct case.

The second is an issue that I've noticed with the Tcl glob function on case-insensitive HFS+ filesystems, which is used in "proc installed" in base/registry1.0/receipt_flat.tcl. The path for the receipt for XviD port is currently ${prefix}/var/db/dports/receipts/XviD/<compound_version>, but on case-insensitive HFS+,

glob -nocomplain -types d ${prefix}/var/db/dports/receipts/xvid/*

succeeds in finding the directory entry, and furthermore returns

${prefix}/var/db/dports/receipts/xvid/<compound_version>

i.e. the returned path contains xvid all in lower case; the proc then parses this path to extract the port name as "xvid".

As a final note, on my system, opening ${prefix}/var/db/dports/receipts/file_map.db in a hex editor now seems to show ${prefix}/include/xvid.h as belonging to "XviD", but when I first encountered this problem two weeks ago (before I hosed file_map.db by trying to edit it by hand, and had to re-install), it looked like it was registered to "xvid". My previous installation was first installed about a year ago, so there may have been some changes in the meantime that have resulted in the issues observed here.

I think there has been discussion about whether port(1) should behave case-sensitively or not with respect to port names fed to it, so perhaps this opportunity should be used to resolve this.

Change History (5)

comment:1 Changed 17 years ago by boeyms@…

Sorry James and Kevin; I send you guys this ticket since you seem to be the most active on base. I hope you don't mind.

comment:2 Changed 17 years ago by markd@…

This looks like a duplicate of #11759.

comment:3 Changed 17 years ago by kballard (Lily Ballard)

Resolution: duplicate
Status: newclosed

I agree. Marking as dupe of #11759.

comment:4 Changed 17 years ago by nox@…

Priority: ExpectedNormal

comment:5 Changed 17 years ago by jmpalacios (Juan Manuel Palacios)

Milestone: MacPorts 1.4
Note: See TracTickets for help on using tickets.