Date: Mon, 29 Aug 2011 13:14:02 -0500 From: "Conrad J. Sabatier" <conrads@cox.net> To: freebsd-ports@freebsd.org Subject: Re: MASTER_SITE_SOURCEFORGE: how do *you* handle it? Message-ID: <20110829131402.15dad07b@cox.net> In-Reply-To: <4E5BABD0.9090300@xaerolimit.net> References: <20110828210511.3d2e0604@cox.net> <4E5BABD0.9090300@xaerolimit.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Aug 2011 11:10:08 -0400 Chris Brennan <xaero@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@cox.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110829131402.15dad07b>