From owner-freebsd-ports@FreeBSD.ORG Mon Aug 29 18:14:09 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D1621065676 for ; Mon, 29 Aug 2011 18:14:09 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by mx1.freebsd.org (Postfix) with ESMTP id 2725A8FC08 for ; Mon, 29 Aug 2011 18:14:08 +0000 (UTC) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20110829181408.HUJJ32702.eastrmfepo203.cox.net@eastrmimpo02.cox.net> for ; Mon, 29 Aug 2011 14:14:08 -0400 Received: from serene.no-ip.org ([98.164.83.25]) by eastrmimpo02.cox.net with bizsmtp id SJE71h00d0YnB6A02JE8ha; Mon, 29 Aug 2011 14:14:08 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020208.4E5BD6F0.00AA,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=ax4i8a8snyEA9uWfgWYmXW+3D+RWNhitQWxcW0Jxd9c= c=1 sm=1 a=wWrJEvAoo_wA:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=2vO5UZG1h46htWAnE/rx2g==:17 a=G0q-payyAAAA:8 a=FP58Ms26AAAA:8 a=kviXuzpPAAAA:8 a=PcoLsz3Ql31y4TSCaOEA:9 a=hdlFTQfFunIibjB3DHYA:7 a=CjuIK1q_8ugA:10 a=673AGJE-P7wA:10 a=4vB-4DCPJfMA:10 a=GhoF0X3YURPxc8pE:21 a=8FYdWz4nTSjzamoM:21 a=2vO5UZG1h46htWAnE/rx2g==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from cox.net (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id p7TIE7oa033786 for ; Mon, 29 Aug 2011 13:14:07 -0500 (CDT) (envelope-from conrads@cox.net) Date: Mon, 29 Aug 2011 13:14:02 -0500 From: "Conrad J. Sabatier" To: freebsd-ports@freebsd.org Message-ID: <20110829131402.15dad07b@cox.net> In-Reply-To: <4E5BABD0.9090300@xaerolimit.net> References: <20110828210511.3d2e0604@cox.net> <4E5BABD0.9090300@xaerolimit.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: MASTER_SITE_SOURCEFORGE: how do *you* handle it? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 18:14:09 -0000 On Mon, 29 Aug 2011 11:10:08 -0400 Chris Brennan 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/" 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