Re: [gentoo-dev] Handling Launchpad SRC_URI

[Robert Buchholz]

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