Reopen a request for gpgme in Core

[seth vidal]

> By default, KMail in FC3 only supports OpenPGP through built-in GPGME
> and external GnuPG.
> 
> How would we obsolete the cryptplug package?
> 
> For KMail, which has been our only cryptplug user, it would work to
> make a gpgme update "Obsoletes: cryptplug". E.g. the gpgme and gnupg
> packages in the fedora.us queue is built with OpenPGP and S/MIME
> support. But it would not be entirely correct, since gpgme >= 0.4.5
> is not a direct successor of cryptplug.
> 
> We've discussed opportunity for meta-packages a long time ago, but
> never implemented them. Where a package is not moved from Extras into
> Core, we need ways to obsolete "old cruft" ourselves. One way to
> achieve that in an upgrade would be to create and main a meta package
> like "fedora-extras-release-3".
> 
> Thoughts anyone?

I think the reason is that metapackages just end up picking up lots of
cruft and maintaining that package, going forward, is just a pain in the
arse.

Why not just have comps.xml-style groups and use the
groupinstall/groupupdate options?

Counting on obsoletes, I've found, is not always a good idea. Not to
mention the very real possibility of something moving out of core to
extras and then, for various dependency reasons, having to move back.

as much fun as it is to have circular obsoletes, I think I'll pass.

-sv