Ok this is my first time doing an ebuild so chances are I screwed something up. However, it works for me as far as I can tell. But be aware. This is a version bump for gpgme 0.4.0. This is the first "stable" release in this series. For my purposes this is needed for GPA 0.6.0 (the second ebuild I have made in my life). Hope I submitted this properly and that it all works, forgive me if it doesn't.
Created attachment 6819 [details] ebuild for gpgme-0.4.0
Created attachment 7172 [details] gpgme-0.4.0.ebuild I've created a slighly cleaner ebuild, using use_enable and removing the gpgmeplug option since it seems not to be implemented in this release of gpgme.
1. This can and should be slotted since api changes will conflict with gpgme-0.3 and cause apps such as sylpheed to stop working 2. gpgmeplug is now a separate build called cryptplug 3. If I can, I will try to update the ebuild with these changes
According to gpgme devs, the shared libraries of 0.3 and 0.4 can coexist. Unfortunately, I have no idea how to do that. But that shouldn't stop this ebuild from being included since the new version of gpa depends on it.
I think having to slot this package would be an unfortunate complication. The API differences between 0.3 and 0.4 are minor, updating an existing program to use 0.4 should be relatively easy. This is a library still in development, the API is expected to change over time. It shouldn't take long before there is a "stable" release in the 0.4.x series. Do the gpgme developers intend to maintain the 0.3.x series?
Created attachment 7365 [details] gpgme-0.4.0.ebuild Well, here's a slotted ebuild that forces everything to end up named 'gpgme4', to make the GPA ebuild work with this, the econf line must appear as: GPGME_CONFIG=/usr/bin/gpgme4-config econf `use_enable nls` It works, but it may be wrong-headed. Waiting for more input before I commit this.
Oops, the first SLOT="0" needs to be removed.
I don't think they will maintain the 0.3 line (0.3.14 is the latest). The only reason I suggest slotting is because they are apps that need one or the other, such as gpa 0.6 vs. sylpheed, and the devs did say 0.3 and 0.4 can coexist. Since 0.4 is so new and only gpa depends on it right, I think having both is a good thing, as long as hassles are minimal. Later on, after a few more 0.4 releases, hopefully other apps will have upgraded, and 0.3 can be phased out. But API will continue to happen, so having a slot system would probably be beneficial.
*** Bug 14369 has been marked as a duplicate of this bug. ***
Since there doesn't seem to be any resistence to my hacked-up ebuild, I committed it to the tree (masked).
Well, it doesn't cause any conflict for seahorse-0.6, which depends on gpgme-0.3.14. But I think the real test is whether gpa-0.6, which needs gpgme-0.4
db fix
*** Bug 15089 has been marked as a duplicate of this bug. ***
