Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 57193 - [New Version] app-crypt/gpgme update to 0.9.0
Summary: [New Version] app-crypt/gpgme update to 0.9.0
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High enhancement (vote)
Assignee: Daniel Black (RETIRED)
Depends on: 57795 59702 59850 60540 63392
Blocks: 23904 42081 57200 59875 60245
  Show dependency tree
Reported: 2004-07-15 09:39 UTC by Torsten Stets
Modified: 2004-09-12 03:36 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---

ebuild (app-crypt/gpgme-0.9.0.ebuild) (gpgme-0.9.0.ebuild,1.44 KB, text/plain)
2004-07-15 09:41 UTC, Torsten Stets
My ideas for the ebuild... please tell me if I'm wrong. (gpgme-0.9.0-r1.ebuild,1.66 KB, application/octet-stream)
2004-08-07 14:08 UTC, Doug Goldstein (RETIRED)

Note You need to log in before you can comment on or make changes to this bug.
Description Torsten Stets 2004-07-15 09:39:32 UTC
Mainly just copying the ebuild for 0.4.7 to 0.9.0. SLOT changed from 0.4 to 0.9 and with that changed the substitutions from *4 to *9. 

Reproducible: Always
Steps to Reproduce:
Comment 1 Torsten Stets 2004-07-15 09:41:41 UTC
Created attachment 35485 [details]
ebuild (app-crypt/gpgme-0.9.0.ebuild)
Comment 2 Daniel Black (RETIRED) gentoo-dev 2004-07-17 22:00:44 UTC
Why should there be a new slot? Is the .4 version incompatible with the .9 version or is there any other reason for both to exist on the same machine?
Comment 3 Torsten Stets 2004-07-19 00:48:55 UTC
I thought it would be reasonable to change to slot because of the version bump. 
Version 0.4.x -> SLOT 0.4
Version 0.9.x -> SLOT 0.9
No other reasons. 
Sorry if that was wrong. 
Comment 4 Daniel Black (RETIRED) gentoo-dev 2004-07-20 18:22:52 UTC
Just a quick explanation on SLOTS. Slots are for when you want to support 2 or more versions of the same package on you system. e.g. gcc-2.96 and gcc-3.4. Or if a package e.g. sys-libs/db need to exist multiple times on a system to forfill a range of other packages.

To check if a package needs an update - check the changelog and see if there are major API changes and test the package with the same ebuild and then try to compile packages that depend on this one. If it breaks there is some api changes. The decision as to whether to use SLOTS then it based on which is the easiest solution; Fixing the libs, the programs they depend on, or just giving up and using SLOTS.

No need to apologise, its part of the learning process. I'm looking at these factors now. If you want to test youself - remove all gpgme versions. compile 0.9.0 using the 0.47 ebuild. Recompile something that depends on it and post the result here. If I do go for SLOT and turn out to be wrong, it's a bit messy to undo. All help appreciated.
Comment 5 Daniel Black (RETIRED) gentoo-dev 2004-07-22 16:03:14 UTC
This is going to be a bit messy - 2 apps (that I've tried) that depend on this one use removed bits of code. I'm hoping to keep this at the same slot and fix the applications however I'm very short of time. Any links or code to application fixes please post here too. Please help. This is a community distribution, it depends on you much more than me.
Comment 6 Daniel Black (RETIRED) gentoo-dev 2004-07-28 20:59:47 UTC
Things that depend on gpgme and their maintainers

app-crypt/cryptplug/cryptplug:=app-crypt/gpgme-0.3.14	bug-wranglers
app-crypt/gpa/gpa:>=app-crypt/gpgme-0.4*		bug-wranglers
app-crypt/seahorse/seahorse:=app-crypt/gpgme-0.3.14	gnome
dev-python/pyme/pyme:>=app-crypt/gpgme-0.3.9		python
dev-tcltk/tclgpgme/tclgpgme:=app-crypt/gpgme-0.3*	bug-wranglers
mail-client/balsa:=app-crypt/gpgme-0.3.14*		gnome
mail-client/sylpheed:<app-crypt/gpgme-0.4		net-mail
mail-client/sylpheed-claws:=app-crypt/gpgme-0.3.14	bug-wranglers
mail-filter/anubis:>=app-crypt/gpgme-0.3.13		net-mail

Any links to getting these packages working with gpgme-0.9.9 appreciated.
Comment 7 Torsten Stets 2004-07-30 05:22:34 UTC
Gpa compiles against gpgme 0.9.0 but then seems to have problems.
The following programs are not intended for use with gpgme 0.4 or higher:
Pyme has a Version 0.6.0 which could work with gpgme-0.9.0, but I'm not sure.
Balsa uses since Version 2.2.0 gpgme-0.9.0 (see Bug #57200)
Comment 8 Gregorio Guidi (RETIRED) gentoo-dev 2004-07-30 06:12:30 UTC
Looking at the diff between 0.4.7 and 0.9.0, you will find that there are 
minimal code changes: 0.9.0 is an 'interface cleanup' release, intended to
bring users of the developer branch (0.4.x and now 0.9.x) towards the 
interface of gpgme-1.0.
(the api of 0.9 and 0.4.7 are not incompatible, though, 0.9 just add something, without removing)

Ideally, 0.9 should have SLOT="1", and 0.4.x should go out of the portage tree
in a not so far future, but there's still the problem due to gpgme-0.3 branch
taking all the libraries names...
Comment 9 Daniel Black (RETIRED) gentoo-dev 2004-07-30 07:31:12 UTC
I follow your logic. There are now 2 options:
1. Continue with a different name for the 0.4-0.9-1.0 series and yes a SLOT=1 is appropriate.
2. Rename the libraries that depend on version 0.3 and make their dependencies use the appropriate libraries. Make the 0.9 series then use the basic library names.

I'm in favour of the second. Dependency maintainers - do you agree?
Given sylpheed appears to be still in development I assume it will update its dependancy on gpgme-0.9+ at some stage.
Comment 10 Daniel Black (RETIRED) gentoo-dev 2004-07-30 19:28:24 UTC
Caleb since your interested.
Comment 11 Daniel Black (RETIRED) gentoo-dev 2004-07-31 18:12:08 UTC
Proposed plan to implement this version bump in future proof (resistant anyway) way that doesn't break everying and realy just tries to simplify stuff:

Step 1:

Ebuilds that depend on the 0.3 branch are to be marked with an explicit upper version that they depend on. Also check if the upper version can be raised easily as this will reduce the number of ebuilds in step 3.

(setting the groundwork so future steps don't break anything)

Step 2:
Ebuilds in the >=0.4 branch are to be marked with an explicit upper version (i.e. <=gpgme-0.4.7).

(setting the groundwork so future steps don't break anything)

Step 3:
Add a 0.3 ebuild for gpgme (+ 1 revision) that compiles the gpgme to /usr/lib/libgpgme3*. Do this for every dependancy version identified in step 1.

(setting the foundation for new ebuilds to depend on gpgme-0.3*)

Step 4:
Create for the each ebuild that depends on the gpgme-0.3 branch a new ebuild (with a revision bump) that explictly depends on the step 3 version(s) of the ebuild. 

(providing ebuilds that depend on the new 0.3 branch so the old ebuilds using the filename space can be removed)

Step 5:
Replace the 0.9.0 ebuild to install to SLOT=1 and using the standard gpgme namespace. This will be marked incompatible with pre 0.3 namespace ebuilds (except for those created in step 3)

(add the version bump as this bug asked for. Put this in standard filename space)

Step 6:

Commit revision bumps for post 0.4 ebuilds to depend on the 0.9.0 ebuild in step 5.

(use the new 0.9 gpgme ebuild)

Step 7:

What a while for bug reports on packages and fix them approprately.

(probably innevertable)

Step 8:

Remove the old version 0.3 gpgme ebuilds and their dependancies. Mark the new gpgme ebuilds that depend on version 0.3 stable (with the new gpgme 0.3 ebuilds).

(horay no more conficts in gpgme ebuilds)

Remove 0.4* ebuilds and their dependancies. Mark ebuilds that depend on version 0.9+ stable (and gpgme version 0.9 too)

(all version bumped)

Does this suit everyone? - bug-wranglers, gnome, net-mail - I realy want your acceptance here cause I cannot proceed otherwise.

This will make your ebuilds look less like hacks (sed jungles) for all post 0.9 ebuilds. gpgme-0.3 ebuilds will be measier however it looks like most aren't going to version bump soon.

net-mail - sylpheed may be the exception to this however I imagine they will come to the modern gpgme-0.9 age soon.

Comment 12 Colin Tinker 2004-08-01 06:16:40 UTC
As I use kmail from kde 3.3 b2 I agree as gpgme >0.4.5 is required but not installed in its own dir eg gpgm9 but globaly.
Comment 13 Daniel Black (RETIRED) gentoo-dev 2004-08-07 01:41:21 UTC
versions gpgme-0.3.14-r1.ebuild and gpgme-0.9.0-r1.ebuild commited representing the new versions in their new slots (masked until current ebuilds don't accidently depend on them).

gpgme-0.3.14-r1 installs:
/usr/lib/ -> 1091862406
/usr/lib/ -> 1091862406
+ some docs

To compile with 0.3.14-r1 you will need the kind of seds that are used in 0.4+ ebuilds

gpgme-0.9.0-r1 installs in the standard locations (as <0.3.14 did) and For 0.9.0-r1 standard config make without too may complicasions to do with gpgme are required.

Depandancy maintainers. Please:
make things that currently depend on 0.3.14 DEPEND= <=app-crypt-0.3.14
create a new version of these ebuilds that depend on 0.3.14-r1. As I wish to remove versions <=app-crypt-0.3.14 (as they confict with 0.9.0-r1+)

Make a new version of ebuilds that depend on gpgme-4+ depend on >=app-crypt-0.9.0-r1. This will involve removeing most of the complication.

I'll look after the bug-wranglers ebuilds.
Comment 14 Gregorio Guidi (RETIRED) gentoo-dev 2004-08-07 11:24:37 UTC
Thanks for doing the dirty work, Daniel.
While you're at it, the dependencies of gpgme need a lot of cleanup:

> >=sys-libs/zlib-1.1.3
> sys-apps/gawk
> sys-devel/libtool
> sys-devel/gcc
These are pointless.

> >=app-crypt/gnupg-1.2.2
> smime? ( >=app-crypt/newpg-1.9.6 )
newpg-1.9.6 does not exist, support for smime comes from
gnupg-1.9.x (I suppose this was the intention)

> nls? ( sys-devel/gettext )
gpgme does not have support for gettext! (and the gettext dep would be useless 
even in that case).

> RDEPEND="virtual/libc
> 	dev-libs/libgpg-error"
Why the DEPENDs are not in RDEPEND? RDEPEND could be dropped.

So please in 0.9.0 put something like this:
(the version numbers for gnupg are takn from,
I think the configuration that makes kmail usable could be considered
a reasonable default)

	# substitute the above dep with the following ones
	# when gnupg-1.9.x gets unmasked, and introduce the
	# smime use flag properly in use.local.desc.
#	!smime? ( >=app-crypt/gnupg-1.2.5 )
#	smime? ( >=app-crypt/gnupg-1.9.10 )

drop RDEPEND, drop nls from IUSE and drop the `use_enable nls` line.
Comment 15 Doug Goldstein (RETIRED) gentoo-dev 2004-08-07 14:06:39 UTC
Well Daniel asked me to hack at this for a bit. Here's my take and tell me if I'm wrong.

I've made all the corrections that Gregorio mentioned in comment #14.

But I've still got issues with leaving this SLOTed in 0.4 and installing into /usr/include/gpgme4 as well as switching everything to gpgme4.

Either it should be reSLOTed to 0.9 or just to 0 (or if you want to 1) and the .4/.9 stuff should be dropped. Because this is the direction of the library. gpgme 0.3 should be the special case and have the .3 in everything.
Comment 16 Doug Goldstein (RETIRED) gentoo-dev 2004-08-07 14:08:45 UTC
Created attachment 36978 [details]
My ideas for the ebuild... please tell me if I'm wrong.
Comment 17 Daniel Black (RETIRED) gentoo-dev 2004-08-07 19:41:25 UTC

Thanks was still work in progress. Thanks for the pointers I undoubtly would of missed something and this info realy does help.

DEPEND are what is needed to create the library. RDEPENDS are whats neeed at runtime. a ldd on the created libraries will list these RDEPENDS.


Plan is to remove all SLOT=0 and SLOT=.4. Just waiting for ebuilds that depend on SLOT=1 (0.9.0+) to be introduced (SLOT=1 conficts with SLOT=0 at the moment).

Thanks for the ebuild. The commit I did must not have taken. It was quite similar.
Comment 18 Daniel Black (RETIRED) gentoo-dev 2004-08-07 20:37:33 UTC
compile error with app-crypt/gpgme-0.3.14-r1. will fix today sometime.

Possible conflicts with package newpg. Need to isolate tests into src_test routine.

gpgme-0.9.0-r1 should work fine.


mail-client/sylpheed-claws (cvs version supports 0.9+ awaiting next release or time to do a version based on cvs).

app-crypt/seahorse still todo - have to talk to gnome people.

bug 59702 should solve pyme

Others - weren't simple - work in progress.
Comment 19 Spider (RETIRED) gentoo-dev 2004-08-08 11:06:09 UTC
you can' have #comments inside DEPEND="" strings.

Comment 20 Daniel Black (RETIRED) gentoo-dev 2004-08-09 06:32:23 UTC
I think  0.9.0-r1 is installing header in wrong spot - should be /usr/include/gpgme.h?

Gregorio, Doug any progress with dev-tcltk/tclgpgme. Patches welcome.

seahorse fixed. sylpheed-claws fixed.
Comment 21 Gregorio Guidi (RETIRED) gentoo-dev 2004-08-09 12:29:52 UTC
>I think  0.9.0-r1 is installing header in wrong spot - should be /usr/include/gpgme.h?

There are two possibilities:
gpgme-0.3.x installs /usr/include/gpgme3/gpgme.h and
gpgme-0.9.x installs /usr/include/gpgme/gpgme.h


gpgme-0.3.x installs /usr/include/gpgme3.h and
gpgme-0.9.x installs /usr/include/gpgme.h

right now it's kind of both (0.3.14-r1 installs /usr/include/gpgme3/gpgme3.h),
but the first one has the advantage of decreasing the amount of patching and sed-ing, in both the gpgme ebuild itself and in client apps.

for instance, for dev-tcltk/tclgpgme in the first case we just add

export GPGME_CONFIG=${ROOT}/usr/bin/gpgme3-config

while in the second case we must add (like you did for seahorse)

export GPGME_CONFIG=${ROOT}/usr/bin/gpgme3-config
sed -i -e 's:gpgme\.h:gpgme3\.h:' tclgpgme.c

in src_compile()
Comment 22 Daniel Black (RETIRED) gentoo-dev 2004-08-16 04:45:04 UTC
Gregorio, thanks -well pointed out. Will take nice and easy approach 1.

Nobody told me I did econf twice in 0.3.14-r1 - wake up everybody.

In comment 18 I was wrong about syphleed-claws - its stuck at version gpgme-0.3

Packages refixed:

Bugs that need fixing before this can be stabilised 

dev-python/pyme bug# 59702
mail-filter/anubis bug #57795
mail-client/sylpheed bug #60540

Updating gpgme-0.3.14 dependant progams should be as easy as:
<       crypt? ( <app-crypt/gpgme-0.4 )
>       crypt? ( =app-crypt/gpgme-0.3.14-r1 )

Before configure:
>       # for gpgme support
>       export GPGME_CONFIG=${ROOT}/usr/bin/gpgme3-config
>       # For gnupg-1.9
>       if [ -x ${ROOT}/usr/bin/gpg ];
>       then
>               export GPG_PATH=${ROOT}/usr/bin/gpg
>       elif [ -x ${ROOT}/usr/bin/gpg2 ];
>       then
>               export GPG_PATH=${ROOT}/usr/bin/gpg2
>       fi

After everying is commited and stable bugs 23904, 42081, 57200, 59850,59875, 60245 will be solved!
Comment 23 Daniel Black (RETIRED) gentoo-dev 2004-08-16 04:55:03 UTC
Adding crypto herd herd.
caleb and cardeo - I don't think you are interested any more?
Comment 24 Daniel Black (RETIRED) gentoo-dev 2004-08-16 07:06:24 UTC
dev-tcltk/tclgpgme-1.0-r1 fixed too
Comment 25 Gregorio Guidi (RETIRED) gentoo-dev 2004-08-29 03:56:33 UTC
Caleb or Daniel, please update kdepim-3.3.0, it is just a matter of setting
>=app-crypt/gpgme-0.9.0-r1 in DEPEND and removing the 'export GPGME_CONFIG' line

Comment 26 Daniel Webert 2004-08-29 07:58:24 UTC
*** Bug 62041 has been marked as a duplicate of this bug. ***
Comment 27 Andrej Kacian (RETIRED) gentoo-dev 2004-09-08 12:49:01 UTC
Anubis has been fixed. Daniel, thanks for the patches.
Comment 28 Daniel Black (RETIRED) gentoo-dev 2004-09-12 03:36:13 UTC
Well 27 comments later and a version bump has been done. Once bug 63501 is solved I'll put in a bug report to stabilise gpgme-0.3.14-r1 and 0.9.0-r1 and eventually remove all others. Any problems please open a new bug report. I don't realy want to read through this again :-)