Unable to update/build "security/gpa"
dougb at FreeBSD.org
Mon Jun 21 19:07:42 UTC 2010
On 06/20/10 09:30, Jason E. Hale wrote:
> On Sunday, June 20, 2010 06:55:52 you wrote:
>> FreeBSD-PRERELEASE 8.1 amd64
>> Since the release of "libassuan-2.0.0", I have not been able to
>> update or reinstall "security/GPA". All of the other ports appear
>> to build fine.
I'm sorry to hear that you're having problems. At this time if you want
to use gpa the only alternative is to use gnupg 1.x. I realize that's
not necessarily an attractive alternative, but see below.
> I know all too well. Unfortunately a committer made a hasty move and
> updated libassuan to version 2.0.0 and then made gnupg 2.x use the
> newer libassuan.
It wasn't hasty. My first public message to maintainers of affected
ports went out on May 11th. According to this message on May 12th you
seemed quite optimistic that you would be able to deal with gpa, and
actually gave some helpful information on some of the other ports
as well, which I appreciated.
In subsequent messages I agreed with your suggestion that handling
everything at once was the best option, however after repeated prompting
neither you, nor any of the other maintainers came forward with patches
to accomplish that. Due to a bug in gnupg 2.0.14 (albeit a minor one) I
thought it was important to move forward with the upgrade prior to
FWIW, I agree that the situation with libassuan 2.x being incompatible
with 1.x is not ideal, but it's not something I have any control over.
The authors of the software made that choice, and the theory is that the
benefits outweigh the costs. I hope they are right. :)
> This of course turns into a chain of conflicts because everything
> else that depends on libassuan 1.x usually needs gnupg 2.x as well.
Anything that depends on gnupg 2.x will also work with 1.x as it applies
to strict gnupg functionality. Once again, I realize that this is not
necessarily the most desirable option, however it _does_ leave the users
with a path.
It's probably also worth pointing that out of the 3 remaining ports that
need to be fixed, kdepim will be fixed in the next release, and the kde
folks have already committed to dealing with it. In opensc the
dependency is optional, and the feature that depends on it will be
removed in the next version anyway.
> I am working to resolve the situation for my ports,
Do you have ports other than gpa that are affected by this change?
> however, the author of gpa has not released a version that will work
> with libassuan 2.x.
I asked Werner about this, and unfortunately it's not likely that he
will be able to cut a new release of gpa prior to our 8.1-RELEASE. Are
you still optimistic about using what's in their source tree to produce
a patch for libassuan 2.x compatibility? I downloaded their tree but
haven't had time to look at it much since I've had other urgent issues
> There is a ports freeze now too, so I am not sure if my updates will
> even go through for a while.
Just in case I haven't been clear, if you get a patch for gpa I will
commit it. Making it work with libassuan 2.0.0 definitely falls into the
category of what's acceptable to commit during the slush.
> If you really need to use gpa immediately, I suggest downgrading
> everything that depended on libassuan 2.x to use libassuan 1.x.
At this point the only thing that depends on it is gnupg 2.x (and
dirmngr, but the only thing that depends on it is gnupg 2.x).
... and that's just a little bit of history repeating.
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
More information about the freebsd-ports