Bug 16992 – py-gnupg-0.3.2.ebuild (New Package)

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Derek Greentree 2003-03-06 17:55:59 UTC]

Hi there.
Attached to this bug is py-gnupg-0.3.2.ebuild, and ebuild I made for a py-gnupg
which is a python interface to GnuPG. A pretty useful tool to enable python apps
to talk to GnuPG.
The logical place for this seems to be dev-python/py-gnupg.
The homepage for this module is http://py-gnupg.sourceforge.net/.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

[Comment 1 Derek Greentree 2003-03-06 17:56:53 UTC]

Created attachment 9047 [details]
py-gnupg-0.3.2.ebuild

The ebuild

[Comment 2 Derek Greentree 2003-03-06 17:59:08 UTC]

Comment on attachment 9047 [details]
py-gnupg-0.3.2.ebuild

# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header: $

DESCRIPTION="A Python module to interface with GnuPG."

HOMEPAGE="http://py-gnupg.sourceforge.net/"

# Point to any required sources; these will be automatically downloaded by
# Portage.
SRC_URI="mirror://sourceforge/py-gnupg/GnuPGInterface-0.3.2.tar.gz"

LICENSE="LGPL-2.1"

SLOT="0"

KEYWORDS="~x86 ~ppc ~sparc ~sparc64 ~alpha"

IUSE=""

DEPEND="virtual/python >=gnupg-1.2.1-r1"

#Unzipped dirname
DIRNAME="GnuPGInterface-0.3.2"

S=${WORKDIR}/${DIRNAME}

src_compile() {
	python setup.py build || die
}

src_install() {
	python setup.py install --root=${D} || die
}

[Comment 3 J Robert Ray 2003-06-26 00:13:12 UTC]

Reassigning bugs due to lack of time.

[Comment 4 Rob Cakebread (RETIRED) 2003-09-14 11:04:31 UTC]

Created attachment 17705 [details]
py-gnupg-0.3.2.ebuild

I used "inherit distutils" and deleted the src_compile and src_install funcs,
set the DOCS var to add some documentation that wasn't being installed.

Alastair, I tested this and it works. I've used this in a previous project of
mine and it performed well.

[Comment 5 Alastair Tse (RETIRED) 2003-09-17 01:16:04 UTC]

thanks. i've committed this now. 

Rob, just a couple of things. I prefer the DOCS variable to be at the bottom, because the package metadata stuff should be at the top of the ebuild. Also, only put in the archs that you've tested for. I know that for python modules they "should" work on all archs, but it is best to be sure.

Finally, one of the deps was missing a category. But those are all minor issues, otherwise the ebuild was good.

[Comment 6 Rob Cakebread (RETIRED) 2003-09-17 09:47:17 UTC]

Ok, that clears up my arch question I was going to ask next time we talked. I know the developer docs say to only put in the arch you tested it on, but I wasn't sure if we should ask the user if they actually tested the ebuild on all the archs they submitted.

On the DOCS location, I'm not sure what you mean about the metadata.
This metadata?
http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-python/py-gnupg/metadata.xml?rev=1.1&content-type=text/vnd.viewcvs-markup

Would the optimal variable locations be:

Custom variables (MY_P etc.)
Default variables
DOCS

for just about every Python ebuild?