Open dak180 opened 3 years ago
nieder
commented
3 years ago Appending installation info to /opt/sw/src/fink.build/root-test-harness-pm5184-3.42-1/opt/sw/lib/perl5/5.18.2/darwin-thread-multi-2level/perllocal.pod
The pm5184 build tried to build for perl5.18.2. This sometimes happen if different perl variants try to build at the same time (probably a cached value someplace). Do you still get this error if you try to build only test-harness-pm5184?
dak180
commented
3 years ago Appending installation info to /opt/sw/src/fink.build/root-test-harness-pm5184-3.42-1/opt/sw/lib/perl5/5.18.2/darwin-thread-multi-2level/perllocal.pod
The pm5184 build tried to build for perl5.18.2. This sometimes happen if different perl variants try to build at the same time (probably a cached value someplace). Do you still get this error if you try to build only test-harness-pm5184?
Interestingly enough that fixed it even when in the general build it was the first up. Is there some better isolation that can be effected to keep this from happening?
nieder
commented
3 years ago @dmacks might be able to answer that one. It seems to only be a problem between 5182 and 5184, but I haven't tried to tease out the relationship as to why it sometimes works to install mixed variants, and sometimes it fails.
dmacks
commented
3 years ago Appending installation info to /opt/sw/src/fink.build/root-test-harness-pm5184-3.42-1/opt/sw/lib/perl5/5.18.2/darwin-thread-multi-2level/perllocal.pod
The pm5184 build tried to build for perl5.18.2. This sometimes happen if different perl variants try to build at the same time (probably a cached value someplace). Do you still get this error if you try to build only test-harness-pm5184?
Interestingly enough that fixed it even when in the general build it was the first up. Is there some better isolation that can be effected to keep this from happening?
That's really weird. The perl directory paths in the *Script all appear to be constructed using Fink::PkgVersion object methods, where the object database has %n-%v-%r as the unique identifier. The perl-version component of the paths is derived from the Type field (not by introspecting perl itself), which is handled very early in the .info file processor in a way that "other" variants' subtype values are completely invisible. Do I understand we don't have a way to reproduce the error in order to debug? For example, if fink ever reindexed its .info collection, we might/might-not be able to look back at the database to see where an incorrect value had been.
nieder
commented
3 years ago It's popped up a large number of times in the mailing lists where someone tries 'fink install foo-pm5182 bar-pm5184' and foo-pm5182 fails trying to put something into %p/lib/perl5/5.18.4 (or -pm5184 into perl5/5.18.2). This is often common when doing fink update-all. The solution has always been to manually install the failing perlmod individually. Then it always correctly installs into the versioned perl path.
dmacks
commented
3 years ago fink/fink/issues/228 is tracking a way to cause the build-process to abort prior to creating the .deb if it builds incorrectly in this way. Still no idea why it's happening. Seems like it's always "building -pm5184 with 5.18.2 paths on 10.14.5" meaning perl-5.18.4 is system-perl. If it's an update-all, then presumably the system previously had perl-5.18.2 as system-perl.
nieder
commented
3 years ago Does this need to stay open? We know the failure cause and there's a specific item to track that in fink itself.
nieder
commented
3 years ago This is hopefully fixed by nieder/fink@0d41a8f87ae88a9f42579dc5bde4a5716b2bde96
Likely needs to be
mkdir -pinstead.