Re: [31868] trunk/dports/science/molden/Portfile
On Dec 10, 2007, at 11:06, jochen@macports.org wrote:
Modified: trunk/dports/science/molden/Portfile =================================================================== --- trunk/dports/science/molden/Portfile 2007-12-10 16:18:31 UTC (rev 31867) +++ trunk/dports/science/molden/Portfile 2007-12-10 17:06:00 UTC (rev 31868) @@ -12,13 +12,14 @@
name molden version 4.6 -revision 1 +revision 2 categories science graphics maintainers openmaintainer jochen master_sites ftp://ftp.cmbi.ru.nl/pub/molgraph/molden distname molden${version} -checksums md5 ab47e1c440c1b445eade07004f93efd8 \ - sha1 e512d0e9f8e4b93938b63e10f18a9719299eb4e3 +checksums md5 b52d66fc61f3d85abba94e36c14b5d85 \ + sha1 2faeea9f970d5430ab0d2863a7f59c1780c56d3e \ + rmd160 c21b9359e30f24942baa6e3b0dd412c793e3ad17
Anyone who already had molden @4.6_1 installed with the old distfile will get a message that the checksums don't match when trying to upgrade. Since the distfile name didn't change (right?), it'll keep using the old distfile which has the older checksum. You should chastise the developers for releasing a stealth-upgrade. Then you should work around the problem in the portfile by defining a different download directory, like this, for example: dist_subdir ${distname}/${version}_${revision} If the developers frequently release stealth upgrades like this, this could be left in the portfile. If not, it could be removed when the next distfile with a new filename is released.
On 10.12.2007, at 18:33, Ryan Schmidt wrote: Hi Ryan, thanks for your suggestions.
Anyone who already had molden @4.6_1 installed with the old distfile will get a message that the checksums don't match when trying to upgrade. Since the distfile name didn't change (right?), it'll keep using the old distfile which has the older checksum.
Your assessment is correct.
You should chastise the developers for releasing a stealth-upgrade.
I guess that is not possible...
Then you should work around the problem in the portfile by defining a different download directory, like this, for example:
dist_subdir ${distname}/${version}_${revision}
Ok, done. Thank you for the suggestion and clarification.
If the developers frequently release stealth upgrades like this, this could be left in the portfile. If not, it could be removed when the next distfile with a new filename is released.
Okay, I leave it in;( How does one clean the old distfiles left around from previous revisions? Would it be possible to run a port clean --all molden from within the Portfile instead of the dist_subdir trick? Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen- Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll
On Dec 10, 2007, at 12:33, Jochen Küpper wrote:
Anyone who already had molden @4.6_1 installed with the old distfile will get a message that the checksums don't match when trying to upgrade. Since the distfile name didn't change (right?), it'll keep using the old distfile which has the older checksum.
Your assessment is correct.
You should chastise the developers for releasing a stealth-upgrade.
I guess that is not possible...
Then you should work around the problem in the portfile by defining a different download directory, like this, for example:
dist_subdir ${distname}/${version}_${revision}
Ok, done. Thank you for the suggestion and clarification.
If the developers frequently release stealth upgrades like this, this could be left in the portfile. If not, it could be removed when the next distfile with a new filename is released.
Okay, I leave it in;(
How does one clean the old distfiles left around from previous revisions?
A user could manually go into the distfiles/molden directory and remove unneeded files. But this is not unique to molden. All ports leave their old distfiles behind, unless the user cleans up manually or runs "sudo port clean --all foo".
Would it be possible to run a port clean --all molden from within the Portfile instead of the dist_subdir trick?
I don't think so. (Well, it's Tcl so anything's possible, but I don't think it should be done.)
participants (2)
-
Jochen Küpper
-
Ryan Schmidt