Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 314053 - ccp4: mv CBIN/CCP4_BIN away from /usr/bin (was: sci-chemistry/ccp4i: incomplete/erroneous rename patches)
Summary: ccp4: mv CBIN/CCP4_BIN away from /usr/bin (was: sci-chemistry/ccp4i: incomple...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Justin Lecher (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 315943
  Show dependency tree
 
Reported: 2010-04-09 08:54 UTC by Johan Hattne
Modified: 2010-06-30 18:55 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Updated 6.1.3-rename-rapper.patch. (6.1.3-rename-rapper.patch,2.17 KB, patch)
2010-04-09 08:55 UTC, Johan Hattne
Details | Diff
Updated 6.1.3-rename-superpose.patch. (6.1.3-rename-superpose.patch,1.08 KB, patch)
2010-04-09 08:56 UTC, Johan Hattne
Details | Diff
Updated 6.1.3-rename-truncate.patch. (6.1.3-rename-truncate.patch,3.45 KB, patch)
2010-04-09 08:56 UTC, Johan Hattne
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Johan Hattne 2010-04-09 08:54:44 UTC
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?
Comment 1 Johan Hattne 2010-04-09 08:55:46 UTC
Created attachment 227089 [details, diff]
Updated 6.1.3-rename-rapper.patch.
Comment 2 Johan Hattne 2010-04-09 08:56:27 UTC
Created attachment 227091 [details, diff]
Updated 6.1.3-rename-superpose.patch.
Comment 3 Johan Hattne 2010-04-09 08:56:53 UTC
Created attachment 227093 [details, diff]
Updated 6.1.3-rename-truncate.patch.
Comment 4 Justin Lecher (RETIRED) gentoo-dev 2010-04-09 09:53:56 UTC
(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?

Comment 5 Justin Lecher (RETIRED) gentoo-dev 2010-04-25 12:17:46 UTC
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.
Comment 6 Justin Lecher (RETIRED) gentoo-dev 2010-04-25 12:30:20 UTC
+*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
+
Comment 7 Johan Hattne 2010-05-04 20:47:28 UTC
(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.
Comment 8 Justin Lecher (RETIRED) gentoo-dev 2010-05-05 06:32:47 UTC
(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.
Comment 9 Johan Hattne 2010-05-05 15:28:25 UTC
(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).
Comment 10 Justin Lecher (RETIRED) gentoo-dev 2010-05-05 15:49:09 UTC
(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.
Comment 11 Justin Lecher (RETIRED) gentoo-dev 2010-06-30 18:55:39 UTC
Done for now. Let see how it behaves.