MASTER_SITE_SOURCEFORGE: how do *you* handle it?

[Conrad J. Sabatier]

On Mon, 29 Aug 2011 11:10:08 -0400
Chris Brennan <xaero at xaerolimit.net> wrote:

> On 8/28/2011 10:05 PM, Conrad J. Sabatier wrote:
> > 
> > In browsing a number of projects recently on Sourceforge, I've
> > noticed that the paths to project distfiles are now using the
> > element "projects" rather than "project".
> > 
> > What I'm looking for is how to declare things in a clean and
> > elegant fashion in a port's Makefile to handle these cases, one
> > that will hopefully not require any revisions for later upgrades.
> > Is it necessary to just scrap the "SF" definition entirely and
> > hardcode the URL?
> > 
> > In addition, I've run across a few projects that use slightly
> > differing versions of the project name, either somewhere in the path
> > or for the distfile name itself.  For example, looking at the
> > "scidvspc" project earlier today, I noticed this:
> > 
> > The link for the distfile is defined as:
> > 
> > http://sourceforge.net/projects/scidvspc/files/source/scid_vs_pc-4.5.tgz/download
> >
> >  Clicking the download link, one is presented with alternatives in
> > case the download doesn't start automatically.
> > 
> > The "mirror" link:
> > 
> > https://sourceforge.net/settings/mirror_choices?projectname=scidvspc&filename=source/scid_vs_pc-4.5.tgz
> >
> >  The "direct link":
> > 
> > https://downloads.sourceforge.net/project/scidvspc/source/scid_vs_pc-4.5.tgz?r=&ts=1314582468&use_mirror=superb-sea2
> >
> >  Frankly, I'm baffled as to how our current definition of 
> > "MASTER_SITES=SF/<something>" is supposed to handle all of this.
> 
> Slightly related and unrelated at the same time. So sorry if I drifted
> too far. I was discussing this very concept about a month ago with a
> friend. I was trying to update my PortableApps.om installation and the
> script I had written to fetch updated apps broke because I couldn't
> figure out how to handle these new url's. It would see SF's idea of a
> direct link is a redirect, thus obfuscating the real servers even more
> and the path the project is in....

Yes, it's kind of crazy what's going on with Sourceforge these days.
Used to be that the URL for a given project's file(s) was a pretty
straightforward, standard affair, with the URL invariably ending with
the name of the file.  Now they're using all these "download" links
instead, with redirects automatically being invoked, as well as
unexpectedly inconsistent elements within the URL.  I'm surprised there
haven't been a lot of reports already of unfetchable distfiles and/or
broken links in ports' Makefiles.

I had to step back from it for a while, as after numerous attempts to
find a clean and simple way to handle the new URL scheme, I got
dizzy.  :-)  Maybe I'll get back to it sometime today.  It may turn out
that there is, in fact, no general, one-size-fits-all solution for this.

I don't know.  Isn't anyone else (ports maintainers in particular)
running into any trouble with this?

-- 
Conrad J. Sabatier
conrads at cox.net