Dennis Gilmore (dennis(a)ausil.us) said:
> For a third-party package we don't ship? It's probably
not going to
> happen at this point. Note that, for example, mutt with gnupg will
> work pretty much the same as it normally does in core - it doesn't
> require libgcrypt.
>
> libgcrypt was updated for a package we do ship (cryptsetup for dm-crypt).
well fedora.us has quite a few packages that do require it ie gpgme gpgme03
cryptplug. mutt needs gpgme03
mutt doesn't use gpgme at all without adding external patches and
rebuilding first.
Ergo, not a concern for Core or Extras, only Alternatives.
kmail uses cryptplug which needs gpgme03 so
you are breaking packages in fedora.us and saying too bad not good
gpgme03 actually builds without newpg just fine, and therefore
doesn't depend on libgcrypt. I assume you've built it that way
explicitly for S/MIME?.
consideration has to be taken to packages in extras and it seems
its not.
TBH, it's the first time I've heard of this conclict. In some cases,
it is impossible to test against the entirety of fedora.us, especially
when it's not all even built for FC2.
so it leaves us to upping gnupg to a version that is considered
alpha to
support the extras tree or does that not come into consideration?
Thats *a* alternative (fedora.us is shipping 'alpha' gpgme, anyway), but
not a good one. Carrying around a libgcrypt1 compat library certainly
seems much simpler, and would be trivial to package.
So far the fedora project seems to be Red Hat doing what it wants
with
slightly more input from others but no real effort to open the project up.
Yes, exactly! We want to ram everything down your throat. MUWHAHAHAHA.
WE WILL BREAK YOUR SOFTWARE AND CRUSH YOU, YOU INSIGNIFICANT WORM!
Next step, looting, pillaging, and rampaging.
We're just trying to add functionality requested by our users.
Bill