Remove generic names from GROMACS binaries
A lot of binaries of GROMACS have very generic names, such as average, highway, luck, wheel and so on, which may clash with other binaries in the system.
Could these be renamed bin -> g_bin?
#1 Updated by Erik Lindahl almost 12 years ago
Yes, we should do this, but it will have to wait until post-4.0.
(our first goal is to improve the release schedules by only fixing real bugs in the release branch - that also gives us a bit more incentive to release version 4.1 within 6 months from now :-)
#5 Updated by Jussi Lehtola almost 12 years ago
(In reply to comment #4)
Wouldn't it be even better to have all binaries (including mdrun)
prefixed by gmx_ ?
(This gets a bit confusing with the source files names in src/tools,
but we can resolve that.)
Yeah, maybe, or just change everything to begin with g_ . Whatever you think is best - gmx_ is more descriptive but g_ is shorter.
Maybe it'd be best to go with gmx_, that way the probability to conflict with names of other software is least..
#9 Updated by Jussi Lehtola almost 12 years ago
(In reply to comment #7)
But please wait with making the final package until version 4.0.1 comes out
which will have fixes for a few small but annoying bugs.
That will probably be on Friday.
Gromacs 4.0 is already on its way to the repositories. Once 4.0.1 is released I will push it to the releases; updates are a lot easier than getting wholly new packages accepted in the distribution.
(In reply to comment #8)
Actually, are you aware that there already is a spec file? If all is well you
can just run make rpm with vanilla gromacs.
Yes, I am. I based some of my new spec file on the specs distributed with Gromacs, but basically had to write it anew since the specs made by Erik don't conform to Fedora's quite strict standards.
You can see my SPEC file at
and the SRPM at
We may also release a 3.3.4 version simultaneously.
OK. But since I didn't get any reply for my mail on Oct 8 (see below) I assumed there is no need for a package for gromacs 3 (I did make one, but withdrew it from the review process).
Also the packaging guidelines are quite strict: there should only be one major version of software distributed. Since having two versions means a lot more huss and Gromacs is backwards compatible, Fedora will only include the latest stable version.
With Fedora EPEL the situation is a bit trickier: the policy is to avoid even minor updates. (See http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies )
This may mean that EPEL 4 and EPEL 5 will stick to Gromacs 4.0 and won't see Gromacs 4.1. At least not until the next big OS update.
I'd prefer if there was a latest'n'greatest repository, too, for EPEL, but there isn't. In principle it's best to have the latest version available installed, but you really can't update GROMACS in the middle of doing a simulation set.
On Wed, 2008-10-08 at 18:30 +0300, Jussi Lehtola wrote:
On Wed, 2008-10-08 at 17:27 +0200, David van der Spoel wrote:
Jussi Lehtola wrote:
are GROMACS 4.0 files binary compatible with GROMACS 3.(3.)x files?
Explanation: I am working on a package of Gromacs 4 that is going to be
included in Fedora. Is there still a need to have a separate package for
Gromacs 3.3.x or is just Gromacs 4 enough?
Gromacs 4.0 can read all old files from gromacs 3.3.
OK. So in your opinion having the latest version is enough?
#14 Updated by David van der Spoel over 10 years ago
Previously mdrun used to be part of the RAID tools on linux boxes. genbox is reported to confict with a raytracing tool. Both mdrun and genbox fall under the category of programs that are being used in scripts a lot, and therefore I'm not touching them.
Instead, I have now picked the low hanging fruit and renamed some of the less used tools to g_XXX, and also kicked out some stuff that was obsolete (average, scrollw). I decided not to touch the configure stuff, too messy, at least in Peter Kasson's proposal.
The following programs were renamed:
g_highway -f $GMXDATA/gromacs/top/highway.dat