#61796 closed defect (fixed)
Activation broken on Tiger
Reported by: | fhgwright (Fred Wright) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.4 |
Keywords: | tiger | Cc: | |
Port: |
Description
A few days ago, "port upgrade outdated" started failing on Tiger (both i386 and ppc), due to activations failing in a manner like this:
mact:~ fw$ sudo port activate p5.28-encode The following versions of p5.28-encode are currently installed: 1) p5.28-encode @3.70.0_0 2) p5.28-encode @3.80.0_0 Enter a number to select an option: 1 ---> Activating p5.28-encode @3.70.0_0 Error: port activate failed: error deleting "/opt/local/var/macports/software/p5.28-encode/mpextractpjw3MR7y/opt/opt/local/opt/local/lib/opt/local/lib/perl5/opt/local/lib/perl5/vendor_perl/opt/local/lib/perl5/vendor_perl/5.28/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/auto/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/auto/Encode/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/auto/Encode/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/auto/Encode/Byte/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/auto/Encode/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/auto/Encode/CN/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/auto/Encode/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/auto/Encode/EBCDIC/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/auto/Encode/opt/local/lib/perl5/vendor_perl/5.28/darwin-thread-multi-2level/auto/Encode/Encode.bundle": file name too long
Note that in this example, it's trying to activate a version that was previously active, so it's not a problem with the port itself. A cursory examination of the git history doesn't show any likely PortGroup candidates, which suggests that it's a problem with base, but this didn't appear until long after updating base to 2.6.4 (with many successful activations).
The directories are so deep that it's not even possible to remove them with rm -rf
, so I'll need to write a program just to clean up the mess. But moving the existing trees to a different directory to "effectively delete" them doesn't help, so it's not just a case of one-time poisoning.
It seems that whatever creates the .../macports/software/<port>/mpextract*
trees is badly broken on Tiger for some reason.
Change History (5)
comment:1 Changed 4 years ago by kencu (Ken)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 Changed 4 years ago by kencu (Ken)
to remove the recursive folders, what worked for me was to open the enclosing folder in the Finder, and drag the troublesome folder into the trash.
comment:3 follow-up: 4 Changed 4 years ago by kencu (Ken)
Bonus points: see if you can help me sort out exactly what is wrong with legacysupport!
comment:4 Changed 4 years ago by fhgwright (Fred Wright)
I though base was supposed to avoid using port-based tools due to exactly this sort of problem. But the fact that activate works with no libarchive port active indicates that the use is opportunistic. Unless there's a good reason for that, it's probably a bug. If there were a broken port needed for deactivate, that would be a really serious problem.
Replying to kencu:
Bonus points: see if you can help me sort out exactly what is wrong with legacysupport!
My first thought was something related to one of the "at" functions, but since many OS versions are missing those, it seems unlikely. Another possibility might be something with strnlen()
, since that was the motivation for using legacy-support
in the first place. I could imagine a fencepost error causing a trailing NUL to be missing in some case, possibly causing unwanted concatenation.
comment:5 Changed 4 years ago by kencu (Ken)
I also first suspected the AT functions. Could be there, as Tiger has no pthread_chdir I has to fall back to the non-pthread version, so it's a bit different.
There also some additions to system functions that involve links, like lchmod IIRC, that might need a deeper look...
duplicate of #61746, fixed by 625eeb4906ebb1133e29f7ab13456324abb92af6/macports-ports