Re: [gentoo-dev] Handling Launchpad SRC_URI

2009-01-25 Thread Marius Mauch
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



Re: [gentoo-dev] Handling Launchpad SRC_URI

2009-01-25 Thread 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


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Handling Launchpad SRC_URI

2009-01-25 Thread Federico Ferri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

 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?

3. (seq24-0.9.0)

SRC_URI=http://edge.launchpad.net/seq24/trunk/${PV}/+download/${P}.tar.bz2;


just another example of different SRC_URI

- --
FF
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl8s0oACgkQV/B5axfzrPssBACffhjl4xMsQSGL8Ez6ngdlkH43
56MAoI9YIesKOrNMg5lYuJyR5xpKUVXP
=wLnZ
-END PGP SIGNATURE-




[gentoo-dev] Handling Launchpad SRC_URI

2009-01-24 Thread Josh Saddler
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?



signature.asc
Description: OpenPGP digital signature