On Dec 29, 2009, at 6:39 AM, Stefan Kaltenbrunner wrote:
> it's not only what some here call the "silly numeric id" - if there is a new release you will have to adjust to the
newfilename as well so I really don't see the problem here.
In general, the only thing you need to update is the version number. For example, I have this script for installing
pgtop:
#!/bin/bash
export VERSION=3.6.2
. `dirname $0`/functions.sh
setup /usr/local/bin/pg_top download http://pgfoundry.org/frs/download.php/1770/pg_top-$VERSION.tar.bz2 build
pg_top-$VERSION
Whenever I seen an announcement for a new version of pg_top, I can just update the version number in this script and
runit to get the new one.
Except I can't. Because it has that fucking ID in it. So instead I have to go to the download page for pg_top (if I can
findit), then find the URL for the new version, find the ID in that URL, then update my script. *Then* I can run it
again.
This, my friends, sucks. It sucks hard. The ID serves no valid purpose aside from allowing one to upload two files with
thesame file name. And who really cares about that anyway? Don't these people use file systems? Crimony.
Even worse is projects like pgTAP include a .spec file in the distribution. But I can't have an accurate URL in the
.specfile until I've uploaded the distribution. I could then update the spec file, create a new tarball and upload it
againwith the proper URL, but then it'd have *another* fucking ID. I can't win.
So having an alternate URL, such as the ftp URL that Dave mentioned a few days ago, is a fine workaround for this
issue.With that, pgFoundry can have any URL it wants for its downloads, and I won't care because I won't use them.
But if the mirrored FTP URLs are unreliable or subject to change with a new version of pgFoundry/KForge/whatever, then
manyexisting applications will likely be screwed.
Best,
David