| Summary: | [New Version] app-crypt/gpgme update to 0.9.0 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Torsten Stets <mai98bmg> |
| Component: | New packages | Assignee: | Daniel Black (RETIRED) <dragonheart> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | bug-wranglers, caleb, cardoe, crypto+disabled, g1gsw, gentoo.bugzilla, gnome, greg_g, jrmalaq, net-mail+disabled, polynomial-c, rockoo |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 57795, 59702, 59850, 60540, 63392 | ||
| Bug Blocks: | 23904, 42081, 57200, 59875, 60245 | ||
| Attachments: |
ebuild (app-crypt/gpgme-0.9.0.ebuild)
My ideas for the ebuild... please tell me if I'm wrong. |
||
|
Description
Torsten Stets
2004-07-15 09:39:32 UTC
Created attachment 35485 [details]
ebuild (app-crypt/gpgme-0.9.0.ebuild)
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? 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. 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. 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. 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. 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: app-crypt/cryptplug app-crypt/seahorse dev-tcltk/tclgpgme mail-client/sylpheed mail-client/sylpheed-claws mail-filter/anubis 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) 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... 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. Caleb since your interested. 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. Agreed? 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. 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/bin/gpgme3-config /usr/lib/libgpgme3.so.6.3.5 /usr/lib/libgpgme3.so.6 -> libgpgme3.so.6.3.5 1091862406 /usr/lib/libgpgme3.so -> libgpgme3.so.6.3.5 1091862406 /usr/lib/libgpgme3.la /usr/lib/libgpgme3.a /usr/include/gpgme3.h /usr/share/aclocal/gpgme3.m4 /usr/share/info/gpgme3.info.gz + 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. 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 http://kmail.kde.org/kmail-pgpmime-howto.html, I think the configuration that makes kmail usable could be considered a reasonable default) DEPEND=">=app-crypt/gnupg-1.2.5 # 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 ) dev-libs/libgpg-error dev-libs/libgcrypt !<=app-crypt/gpgme-0.3.14" drop RDEPEND, drop nls from IUSE and drop the `use_enable nls` line. 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. Created attachment 36978 [details]
My ideas for the ebuild... please tell me if I'm wrong.
Gregorio, 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. Doug, 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. 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. app-crypt/cryptplug app-crypt/gpa mail-client/balsa updated. 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. you can' have #comments inside DEPEND="" strings. 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. >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
or
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()
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: mail-client/sylpheed-claws-0.9.12-r1 app-crypt/seahorse-0.6.3-r1 app-crypt/cryptplug-0.3.16-r1 mail-client/balsa-2.0.15-r2 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: for the DEPENDANCIES: < 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! Adding crypto herd herd. caleb and cardeo - I don't think you are interested any more? dev-tcltk/tclgpgme-1.0-r1 fixed too 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
Thanks.
*** Bug 62041 has been marked as a duplicate of this bug. *** Anubis has been fixed. Daniel, thanks for the patches. 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 :-) |
