On Sunday 25 January 2009, Josh Saddler wrote: > Right now, there's no canonical (heh) way of handling SRC_URI for > projects that have their files at launchpad.net. We need a standard > way of handling Launchpad SRC_URIs, similar to what we do with > mirror://sourceforge/ SRC_URIs. > > 1. Some packages use the launchpadlibrarian.net download redirect, > which results in a non-helpful server-generated number: > > (gnome-catalog) > SRC_URI="http://launchpadlibrarian.net/11326737/${PN}_${PV}.orig.tar. >gz
^^ This just uses launchpad since the file has been removed upstream and Ubuntu happens to archive their source files there. You could just as well use this link: http://snapshot.debian.net/archive/2008/01/19/debian/pool/main/g/gnomecatalog/gnomecatalog_0.3.3.orig.tar.gz or bump to the latest upstream version (and use the sf.net mirror). > 2. Some hack up interesting MY_P stuff: > > (gnome-do-plugins) > MY_PN="do-plugins" > PVC=$(get_version_component_range 1-2) > PVC2=$(get_version_component_range 1-3) > SRC_URI="https://launchpad.net/${MY_PN}/${PVC}/${PVC2}/+download/${P} >.tar.gz" > > (avant-window-navigator-extras) > MY_P="awn-extras-applets-${PV}" > SRC_URI="https://launchpad.net/awn-extras/${PV%.*}/${PV}/+download/${ >MY_P}.tar.gz" > > The AWN-extras ebuild is the closest to the "right" way of doing it, > I think. > > So can we agree on a standard way of treating Launchpad SRC_URIs and > get the handler support into Portage? I haven't seen the inside of administrating a project in Launchpad yet, but that version part ("${PV%.*}") seems to be an arbitrary string, and there are quite a few examples where this URL handler does not work: * https://launchpad.net/tangocms/+download * https://launchpad.net/terminator/+download * https://launchpad.net/get-you/+download * https://launchpad.net/do-plugins/+download [ this is the second package mentioned above, even here some of the links would not work with the proposed solution ] Robert
signature.asc
Description: This is a digitally signed message part.
