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

[boeyms@…]

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.

[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.

[markd@…]

This looks like a duplicate of #11759.

[kballard (Lily Ballard)]

I agree. Marking as dupe of #11759.