making an exception and deleting the old stealth-updated file

[Mojca Miklavec]

Hi,

Answering my own question:

As Joshua pointed out, the files on distfiles.macports.org are deleted
and re-fetched automatically when checksums don't match. This was the
missing part of the puzzle which solved the problem. I only had to
trigger a rebuild after that re-fetching was done.

On Fri, Jan 10, 2014 at 8:32 PM, Mojca Miklavec wrote:
> Hi,
>
> a long time ago (in 2011) a Geant4 data file has been stealth-updated
> (see http://trac.macports.org/ticket/32320). Apparently there was no
> change.
>
> Now this file is still being used in the latest Geant4 10.0 (I find it
> weird, but it wasn't used in 9.6 and it hasn't been updated in
> contrast to the rest) and it is causing me headaches due to the way I
> tried to simplify the port.
>
> I'm currently specifying the data files this way:
>
> set geant.data_versions_10.0 {
>   G4NDL              4.4   checksums
>   G4EMLOW            6.35  checksums
>   PhotonEvaporation  3.0   checksums
>   RadioactiveDecay   4.0   checksums
>   G4NEUTRONXS        1.4   checksums
>   G4PII              1.3   checksums
>   RealSurface        1.0   checksums
>   G4SAIDDATA         1.1   checksums
>   G4ABLA             3.0   checksums
>   G4ENSDFSTATE       1.0   checksums
> }
>
> and I find it painful and ugly to try to make sure that one specific
> 54K file from the list (G4ABLA.3.0.tar.gz) must be fetched from
> https://distfiles.macports.org/geant4/.
>
> I cannot easily change ${dist_subdir} because that would mean that
> lots of data files that already exist would need to be fetched again
> and stored to a second location.
>
> Would it be possible to make just a tiny single-time exception and
> remove the old G4ABLA.3.0.tar.gz from
> https://distfiles.macports.org/geant4/ and the buildbots? I would be
> enormously grateful for that and I'm willing to support any user
> running into the problem and ask him/her to delete the old file. I'm
> guessing the the userbase for geant4 must be small anyway and many
> users need to install fresh when they upgrade the computers anyway.
>
> Now that I look back the port for geant4.9.5-data is actually already
> broken and can only be installed as a binary package (I fixed the
> checksums only after noticing a build failure on the buildbot,
> http://trac.macports.org/changeset/111740/trunk/dports/science/geant4/Portfile).
> Installing it from source should fail. I would need this change
> primarily for a *new* port geant4.10.0-data, so it's not like users
> will run into the problem on a daily basis either. I don't plan to
> revbump or upgrade geant4.9.5-data which also depends on this file.

I solved one part of the problem (on the user end) with the code below
(http://trac.macports.org/changeset/115758).

   pre-fetch {
       set file_abla "${prefix}/var/macports/distfiles/geant4/G4ABLA.3.0.tar.gz"
       if {[file exists ${file_abla}]} {
           if {[md5 file ${file_abla}] != "d7049166ef74a592cb97df0ed4b757bd"} {
               # problematic md5: d2d4e99b14f7a5057f4c10d9c2d647dd
               ui_warn "deleting an old '${file_abla}'"
               file delete ${file_abla}
           }
       }
   }

The other part of the problem on the buildbot (the buildbot first
fetches the files from distfiles.macports.org which had the old file,
so the build failed) ... was resolved automatically as mentioned
above.

Mojca