For ImageMagick I had this livecheck defined: livecheck.check moddate livecheck.url ftp://ftp.imagemagick.net/pub/${name}/$ {name}.tar.bz2 When the portfile was up to date, "sudo port livecheck ImageMagick" returned quickly. However, when a new version of ImageMagick was available, that command took awhile, and I could see from my network traffic meter that it seemed to be downloading the entire archive before telling me the port was outdated. Why is MacPorts downloading the file I specified, when I only wanted it to check its modification date -- a check which MacPorts is obviously already doing correctly, else if would be downloading the archive every time I check. But it's not; it's only downloading it when its modification date has in fact changed.
On Jul 16, 2007, at 3:26 AM, Ryan Schmidt wrote:
For ImageMagick I had this livecheck defined:
livecheck.check moddate livecheck.url ftp://ftp.imagemagick.net/pub/${name}/$ {name}.tar.bz2
When the portfile was up to date, "sudo port livecheck ImageMagick" returned quickly. However, when a new version of ImageMagick was available, that command took awhile, and I could see from my network traffic meter that it seemed to be downloading the entire archive before telling me the port was outdated.
Why is MacPorts downloading the file I specified, when I only wanted it to check its modification date -- a check which MacPorts is obviously already doing correctly, else if would be downloading the archive every time I check. But it's not; it's only downloading it when its modification date has in fact changed.
This livecheck is based on Pextlib "curl isnewer" command, which fetches a file with libcurl by saying please do not fetch it if what you have is older than this date, which is something that only exists with HTTP If-Modified-Since header and there is no FTP equivalent. At least nothing is saved on disk there because the target file is /dev/ null. Using additional libcurl APIs, we might be able to improve this and avoid an FTP fetch (or even a full HTTP fetch when the resource is newer). Paul -- http://paul-guyot.com/
participants (2)
-
Paul Guyot
-
Ryan Schmidt