Bugzilla Bug 114278

I downloaded gamess:
"The archives contain the current GAMESS release, dated June 27, 2005 R3."

donnie@supernova ~ $ md5sum /usr/portage/distfiles/gamess-current.tar.gz
1478f6223f5096d00552806f2a98fd9e  /usr/portage/distfiles/gamess-current.tar.gz
donnie@supernova ~ $ ls -l /usr/portage/distfiles/gamess-current.tar.gz
-rw-r--r--  1 donnie users 6339705 2005-12-02 08:39
/usr/portage/distfiles/gamess-current.tar.gz

donnie@supernova ~ $ grep gamess-current
/usr/portage/sci-chemistry/gamess/files/digest-gamess-05272005
MD5 3aa67e3db20051d372f6fc79c47c3abe gamess-current.tar.gz 5761028

Hrmph!  
  
Thanks Donnie for pointing that out! This is a tricky one (at least for me),   
and I would like to ask or your opinion. The gamess guys do semi-annual releases   
as well as small revision bumps in between. Hence, the current ebuild  
digest is for Jun 27 (R2) while you have downloaded the most current   
one which is Jun 27 (R3). Therefore, in principle, the ebuild should be  
named gamess-05272005.x.ebuild where x is the revision.   
  
Unfortunately (very), the source tarballs are always named gamess.current.tar.gz  
hence there is no easy way for the user to keep tarballs corresponding to  
different revisions/releases in distfiles.  
  
There are a few solutions that come to mind how one could make  
this mess somewhat more transparentl  
  
- renaming the ebuilds to gamess-05272005.x.ebuild and keeping  
  only the most recent one around.  
- renaming the ebuilds to gamess-05272005.x.ebuild and asking the  
  user to copy the gamess-current.tar.gz to    
  /usr/portage/distfiles/gamess-05272005.x.tar.bz instead of just  
  dropping the original file (this should leave the file size and hash untouched 
  I guess). This way we could keep several revisions around without too much 
confusion.  
  
I'll also write an email to upstream asking them if they could rename  
their tarballs, but until this happens if at all I'll have to leave with it.  
  
Thanks for your help,  
Markus  
  
  

(In reply to comment #1)
> There are a few solutions that come to mind how one could make  
> this mess somewhat more transparentl  
>   
> - renaming the ebuilds to gamess-05272005.x.ebuild and keeping  
>   only the most recent one around.  
> - renaming the ebuilds to gamess-05272005.x.ebuild and asking the  
>   user to copy the gamess-current.tar.gz to    
>   /usr/portage/distfiles/gamess-05272005.x.tar.bz instead of just  
>   dropping the original file (this should leave the file size and hash 
>   untouched I guess). This way we could keep several revisions around without 
>   too much confusion.

I rather prefer the latter.

> I'll also write an email to upstream asking them if they could rename  
> their tarballs, but until this happens if at all I'll have to leave with it. 

I remember that they used to have named tarballs. Perhaps they could make them
available again. Another reason for doing so is that people with multiple
versions around get confused about which one any given tarball might be.

(In reply to comment #2) 
> > - renaming the ebuilds to gamess-05272005.x.ebuild and keeping   
> >   only the most recent one around.   
> > - renaming the ebuilds to gamess-05272005.x.ebuild and asking the   
> >   user to copy the gamess-current.tar.gz to     
> >   /usr/portage/distfiles/gamess-05272005.x.tar.bz instead of just   
> >   dropping the original file (this should leave the file size and hash  
> >   untouched I guess). This way we could keep several revisions around without  
> >   too much confusion. 
>  
> I rather prefer the latter. 
>  
 
Me too, and that's what I'll do. I am currently preparing and testing  
a gamess-05272005.3.ebuild (which asks the user to rename+copy the 
tarball) and can hopefully drop it into portage later today and then 
remove the "bad one". 
 
Thanks for your comments! 
 
best, 
Markus  
 
 

I just committed the bumped and renamed ebuild. 
It took a little longer since the new revision contains quite a few changes that 
I wanted to test. Unfortunately, for their new TDHF code the GAMESS folks 
are now using file units >99 which are not supported by the default g77. 
Hence TDHF doesn't run at the moment. 
 
I have created a patch for gcc that should fixes this (I does at least on my system) 
and provided it to the gcc folks (bug #114367). Hopefully they will include 
it if it doesn't cause any other breakage that I am not aware of. 
 
Thanks, 
Markus