From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: The Nixpkgs Monitor Date: Thu, 23 Jan 2014 20:54:49 +0100 Message-ID: <20140123195449.GD13401@debian> References: <87r48awug8.fsf@gnu.org> <20140118120256.GA7593@debian> <87bnz9s3pp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6QMf-0007Fe-Pn for guix-devel@gnu.org; Thu, 23 Jan 2014 14:55:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6QMX-0001jz-3m for guix-devel@gnu.org; Thu, 23 Jan 2014 14:55:01 -0500 Content-Disposition: inline In-Reply-To: <87bnz9s3pp.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?iso-8859-15?Q?Court=E8s?= Cc: guix-devel@gnu.org On Sat, Jan 18, 2014 at 04:35:14PM +0100, Ludovic Courtès wrote: > And what do we do for URIs in http:// or mirror://? What is the particular problem? For ffmpeg, for instance, the uri reads (uri (string-append "http://www.ffmpeg.org/releases/ffmpeg-" version ".tar.bz2")) which gets expanded into "http://www.ffmpeg.org/releases/ffmpeg-2.1.1.tar.bz2". One could try the following: - Remove potentially trailing ".bz2" (to remove digits). - Look for a regular expression "([:digits:].)*["digits:]". If there is only one, this is likely to be the version; try "++" everywhere (in a way that would give "2.1.2", "2.2.0", "3.0.0" in our case, and maybe the same ones without the trailing ".0"); replace them in the string and check whether they exist. If the regular expression is found more than once, there is a good chance that the previous occurrence is the version once again, or a truncation of it, as in http://download.qt-project.org/official_releases/qt/5.2/5.2.0/single/qt-everywhere-opensource-src-5.2.0.tar.xz There is no need to obtain the full list of files in a directory if one can reasonably guess the paths for the next release (and if one does not guess correctly, then the update fails, but not worse than now (assuming that the download server returns a meaningful response when trying to access a non- existing file, instead of an html page printing "404"...)). Andreas