add a special Provides: to all login manager packages

[Toshio Kuratomi]

Colin Walters wrote:
> On Wed, Feb 18, 2009 at 9:30 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
>> Fedora derives its
>> contributor base from the fact that there are many people who are each
>> willing and enthusiastic about working on different things.  As much as
>> possible, we should be attempting to get these people to interact and
>> work on their projects inside of Fedora even when the goals conflict
>> with each other.
> 
> I like this paragraph a lot (and the (snipped) next one which is an
> elaboration), and I agree largely.  My point is really that I do not
> think "all software now in RPM format" is a goal.  It's a *means* to
> various goals, such as providing developer tools, games, and yes,
> multiple desktop environments.
> 
I can agree with this.  Fedora should not measure its worth by saying we
have more software packaged than Foo Distro but less than Bar Distro.
Everybody, package more!

OTOH, Fedora contributors can measure the worthwhileness of contributing
to Fedora by whether they can get the stack of packages they care about
into Fedora.  So my picture of this is while we don't want to encourage
packaging software purely for the sake of packaging, we also don't want
to discourage packaging because it conflicts with other, established
subprojects.

> But as you go farther down the stack, things get less pluggable,
> conflicts increase, impact on the surrounding ecosystem increases.
> And I think it's absolutely reasonable to expect (and receive)
> pushback.
> 
Somewhat.  I think it's reasonable for people to disagree.  However, I'm
not sure if we agree on the definition of pushback.  Let's say that
someone wants to replace Xorg with Yorg, a new windowing system that
makes users happy by feeding them crack.  None of our existing X apps
will work on Yorg.  However, they can be ported with a bit of coding
effort and upstream has patches for a few necessary apps like the
mozilla suite, openoffice, and xterm.

Do we allow Yorg in?  Do we allow rebuilt versions of the apps where an
upstreamed compile time flag has switched from --enable-xorg =>
--enable-yorg?  Do we allow patched rebuilds of the apps where the patch
is not upstream?

I think that this is an area where we have competing interests.  One of
our goals in Fedora is to push the technological envelope.  An actively
developed new windowing system that doesn't conflict with Xorg is
definitely fulfilling that goal.  So keeping Yorg out seems counter to
our goals.  But making Yorg useful puts a burden on our present
maintainers as we need to keep two versions of some apps.  Yorg can't
prosper without some apps to work with.  At the same time, who is going
to pay the cost of maintaining the new versions, triaging bugs that may
be misfiled against the Xorg or Yorg versions, etc?

I think those questions need to be answered.  But we can't go around
outlawing them.  If the new maintainers show up with a triage team ready
to help, coders pushing changes upstream, etc, we need to adapt.

>> Getting too focused on Fedora, the distribution, means that we might
>> have a superior Desktop experience or a superior Server OS but it
>> doesn't mean that we'll have a rich base of contributors who are willing
>> to build new and imperfect software to replace the old and imperfect
>> software that we currently run.
> 
> Building new imperfect software to replace old imperfect software
> doesn't sound very compelling to me...
> 
And yet, that's our exactly what we do ;-)  There's always bugs, always
architectural inadequacies, always something that, in retrospect, should
have been designed differently.  Our hope is that new imperfections are
less painful than the old ones... but they're always there.

>>   It doesn't mean that we'll continue to
>> be innovative or willing to be on the cutting edge.  It doesn't mean
>> that we'll be able to attract a large and diverse group of active
>> contributors.
> 
> I agree we want to be accommodating.  Up to a point.  We have to draw
> a line somewhere between "Let's support Fedora/HURD"[1] and "Here's a
> patch to make the kernel panic if gnome-session isn't in the process
> list".  Where that line is is a matter of debate, and it's useful to
> have, which in fact we are.
> 
So if the line is drawn between "Fedora/HURD" and "kernel panic if
gnome-session isn't in the process list", which are you saying would be
acceptable?  ;-)

> I forgot to point out in an earlier message that there is precedent
> for setting up barriers for low-level software, namely the Fedora 3rd
> party kernel driver policy:
> https://fedoraproject.org/wiki/KernelDriverPolicy
> 
These are the criteria I remember about the kernel:

1) Loadable kernel modules have the same capabilities as the kernel
itself.  That means, loading a kernel module can do anything the kernel
does.  userspace apps, even setuid apps, don't have the same power.

2) If the kernel fails, then nothing works.  If firefox fails, then
people use epiphany.  If gnome fails, people use kde.  etc.

3) Kernel modules have a strict dependence on the kernel that is built.
 So building out of tree kernel modules needs to have infrastructure
support to kick off rebuilds immediately when the kernel is rebuilt.
Having different display managers has no such requirement.

4) Kernel modules are supposed to live in the kernel tree.  They get
many benefits from being there.  Out of tree kernel modules are possible
but not something that the upstream kernel supports.  The interface
between the kernel and modules is unstable.  Different display managers
don't have this dependence on each other.

5) Bugs filed against the kernel can't be relied upon when kernel
modules are present since the kernel module could affect operation of
the kernel in a totally different area.  This is not the same as, but
similar to bugs that might occur when an application doesn't function
due to using a different display manager.

So only one of the considerations applies here.

> All I'm saying is that there should exist similar barriers for
> components between the kernel and the desktop.
> 
Looking at the reason for the kernel ban, I don't think the same
justification for barriers exist in the specific case here.  There could
be other instances with more justification but we'd be better off
discussing them when there's hard facts that we can compare and contrast
against.

It makes the stakes higher :-)

> [1] And if you liked my reaction to new login managers...
> 
I agree that Fedora/HURD is probably something I wouldn't support.
However, I suspect my concerns are very different from yours.  My
reasoning is more infrastructural than policy based.  Currently we don't
have the knowledge-base or hardware to maintain, test, or even build
HURD packages.  Software would have to be coded and tested and kept
running on the infrastructure side to make this a reality.  Lots of work
that no one's volunteered to do.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090219/4139825c/attachment.bin