Error: Package: courier-imap-4.10.0.20120202-2.17.x86_64 (installed) Requires: /bin/perl Removing: 4:perl-5.14.2-211.fc17.x86_64 (@anaconda-0) Not found Updated By: 4:perl-5.14.2-212.fc17.x86_64 (updates-released-local) Not found
From what I can tell, the sequence of events is:
A) A local package's configure script executes "which perl", and puts that into each perl script's hashbang. So:
[root@octopus ~]# which perl /bin/perl This results in: #! /bin/perlB) The rpm package gets built. find-requires that puts this dependency into the package:
requires=/bin/perl C) At install time, rpm seems to be smart to figure this out: [root@octopus ~]# rpm -q --whatprovides /bin/perl perl-5.14.2-211.fc17.x86_64It's smart enough sees that thanks to the symlinks, /bin/perl=/usr/bin/perl. So the package gets installed, with these hashbangs.
D) A perl update hits:[root@shorty x86_64]# rpm -q -l -p perl-5.14.2-212.fc17.x86_64.rpm | fgrep bin/perl
/usr/bin/perl /usr/bin/perl5.14.2 /usr/bin/perlbug /usr/bin/perlthanksThe new perl package contains /usr/bin/perl. At upgrade, dependency resolution is not smart enough to realize that the new package's /bin/perl=/usr/bin/perl, causing a conflict.
Having thought about it, I don't think it's unreasonable to do a "which $PROG", and stick it into the hashbang. I think that's a perfectly reasonable approach, with portability being the goal. The problem I see here, is that Fedora's bash is compiled with the default PATH placing a symlink, /bin, ahead of /usr/bin, in the PATH list:
[root@octopus ~]# strings /bin/bash | grep usr.bin /usr/local/bin:/bin:/usr/binI think that bash needs to be recompiled, with the last two flipped, in the default shell PATH.
Until then, I need to hack each one of my locally-built package's rpm spec scripts, and manually prepend /usr/bin to the PATH. Which sucks.
Attachment:
pgpBzhe_CJtZF.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel