Dennis Gilmore (dennis@xxxxxxxx) 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
