add a special Provides: to all login manager packages

[Jesse Keating]

On Thu, 2009-02-19 at 17:08 +0100, Kevin Kofler wrote:
> Jesse Keating wrote:
> > But we didn't ban non-upstream modules.  Instead we made the kernel team
> > the gateway.  If the module is good enough to provide to Fedora users,
> > it's good enough to be in the kernel package proper.  This gets around
> > the build timing / ordering issue, it prevents newer kernels from
> > causing the module to stop building, it removes the need for gross
> > yum/rpm hacks to handle the packages properly, it removes the need to
> > re-create the initrd after a module update, so on and so forth.
> 
> But the kernel maintainers are extremely selective in what they want to
> build as part of the kernel package, and I don't really blame them.
> Allowing other maintainers to maintain their modules separately means they
> keep most of the burden of keeping them up to date, and they can even be
> temporarily unbuildable in Rawhide without breaking the kernel, we only
> need them working when a release or a kernel update to a release is made.

Wrong, by having them unworking you're preventing that class of users
from testing rawhide.  Bad form.  Rawhide is not a dumping ground to
only be worried about at release time.

> It also means users make a concious decision to install the module, it
> doesn't just magically break their system, so it's much less risky to ship
> experimental or poorly-maintained modules that way.

It also means that users who need that module have to know that module
exists in order to install it, and may not even be able to install
Fedora in the first place because that module isn't available on the
install media.

> 
> If the kernel maintainers were willing to carry appropriately-licensed
> modules like kqemu, current Ralink drivers (I know they're buggy, but it's
> better than not have the hardware work at all) etc., kmod packages would
> not be needed, but there are good reasons not to ship that stuff within the
> kernel (for example it can lock up systems where it's not really needed -
> putting the module into a separate package means only people who asked for
> it got what they asked for), yet there are also good reasons to have it
> available. Thankfully RPM Fusion is providing that service, but it would
> make more sense to have the stuff in Fedora as there are no licensing or
> patent issues with it.
> 

Modules like that should only be loaded if the hardware is present, and
if the hardware is present and the module gets loaded and it crashes
things, that module isn't good enough for Fedora users.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090219/43a17c1c/attachment.sig>