On Sat, 24 Jan 2009 23:38:32 -0800 Josh Saddler <nightmo...@gentoo.org> 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 > > 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? The best way would be to convince upstream to offer a simpler URL scheme. Adding a special handler in the PM would be the worst option (also there is no such thing atm, mirror://sourceforge/ doesn't do anything special). The easiest option would probably be a little helper function in eutils to generate the correct URL, if you *really* need to simplify things (in your examples, the only sligthly odd thing are the version parts in the URL, the MY_P stuff would be needed anyway from what I can see). Marius
