The 6.1.3-rename-rapper.patch, 6.1.3-rename-superpose.patch, 6.1.3-rename-truncate.patch do not rename all instances of rapper, superpose, and truncate. In the case of truncate, one instance is wrongly renamed. Reproducible: Always Steps to Reproduce: 1. Launch ccp4i 2. Run the import_scaled task 3. Choose old truncate (not ctruncate) Actual Results: Doesn't work, because GNU truncate is run instead of CCP4 truncate. Expected Results: A working MTZ file. I don't know whether the suggested patches *really* solve the problem--finding all the instances of the renamed programs in the TCL files is not easily automated and error-prone. Also, I presume the procedure will have to be repeated for each new release of CCP4. I more and more think that the renaming of the CCP4 programs is not the way to go. As far as I can see, the only benefit is that binaries are put in /usr/bin together with (almost) every other executable, while the drawback, apart from the significant maintenance burden, is that every homegrown script needs to fixed. Given that CCP4 truncate has been around since circa 1978 and GNU truncate appeared recently, I don't think upstream will rename it. At least not until ctruncate can truly replace it--and that may be a while. CCP4 was designed to install its applications in a "non-standard" location, pointed to by $CBIN. Could we not find a place for all those little applications? Even though I don't think the FHS explicitly prohibits creating directories in /usr/bin (e.g. /usr/bin/ccp4) I understand that there may be a lot of resistance in doing something like that. What about /usr/libXX, /opt, or something entirely different?
Created attachment 227089 [details, diff] Updated 6.1.3-rename-rapper.patch.
Created attachment 227091 [details, diff] Updated 6.1.3-rename-superpose.patch.
Created attachment 227093 [details, diff] Updated 6.1.3-rename-truncate.patch.
(In reply to comment #0) > CCP4 was designed to install its applications in a "non-standard" location, > pointed to by $CBIN. Could we not find a place for all those little > applications? Even though I don't think the FHS explicitly prohibits creating > directories in /usr/bin (e.g. /usr/bin/ccp4) I understand that there may be a > lot of resistance in doing something like that. What about /usr/libXX, /opt, > or something entirely different? > Donnie, could you please comment on that?
I had some discussion with Donnie about that. Due to the fact, that more and more packages are affected with collision, I am thinking about going the way and seperating the CBIN/CCP4_BIN directory from /usr/bin. Additionally the new location will not be placed in the PATH. The ccp4i should work flawless and all custom scripts should have prepend the CBIN/CCP4_BIN to the command or the PATH. Or the user adds those dirs to the PATH itself.
+*ccp4i-6.1.3-r2 (25 Apr 2010) + + 25 Apr 2010; Justin Lecher <jlec@gentoo.org> + files/6.1.3-rename-rapper.patch, +ccp4i-6.1.3-r2.ebuild, + files/6.1.3-rename-superpose.patch, files/6.1.3-rename-truncate.patch, + -ccp4i-6.1.3-r1.ebuild: + Fixes missing renames, thanks Johan Hattne for giving the patches, #314053 +
(In reply to comment #5) > I am thinking about going the way and seperating the CBIN/CCP4_BIN directory > from /usr/bin. I'm all for it! Where's it going to go? /opt/ccp4? > Additionally the new location will not be placed in the PATH. I don't quite understand why CBIN will not be in PATH.
(In reply to comment #7) > (In reply to comment #5) > > I am thinking about going the way and seperating the CBIN/CCP4_BIN directory > > from /usr/bin. > > I'm all for it! Where's it going to go? /opt/ccp4? It will go to /usr/libexec/ccp4 if there are no concerns. Donnie? From definition /opt is only for non-src packages on gentoo. > > > Additionally the new location will not be placed in the PATH. > > I don't quite understand why CBIN will not be in PATH. > because the question is, whether prepend or append to PATH. In both cases there will be an ambiguity with the progs which now collide. I will make a postinst msg, how to include it into the PATH, but I don't think it would be correct to put it in directly. Only the real unambiguous bins like refmac, will stay in /usr/bin.
(In reply to comment #8) > (In reply to comment #7) > > I don't quite understand why CBIN will not be in PATH. > > because the question is, whether prepend or append to PATH. In both cases > there will be an ambiguity with the progs which now collide. I will make a > postinst msg, how to include it into the PATH, but I don't think it would be > correct to put it in directly. Only the real unambiguous bins like refmac, > will stay in /usr/bin. I think all CCP4 programs will have to be in CBIN--if I remember correctly ARP/wARP always calls REFMAC as "${CBIN}/refmac5". Any ambiguity is inevitable, now that we have several programs with the same name. I don't really see an advantage in not having CBIN in PATH. Default in CCP4 setup script is to append CBIN to PATH (look for ccp4_first_in_path in 40ccp4.setup.sh).
(In reply to comment #9) > I think all CCP4 programs will have to be in CBIN--if I remember correctly > ARP/wARP always calls REFMAC as "${CBIN}/refmac5". Any ambiguity is My plan was to symlink it into CBIN, but also leave it in /usr/bin > inevitable, now that we have several programs with the same name. I don't > really see an advantage in not having CBIN in PATH. Default in CCP4 setup > script is to append CBIN to PATH (look for ccp4_first_in_path in > 40ccp4.setup.sh). > That's right, but I had a discussion about that with Donnie and said that it is definitely a bad idea to have this ambiguity in programs. And as he is a package maintainer for a long time I trust him in this. But this is something which we can simply change, once the rest is done.
Done for now. Let see how it behaves.