nss_db

[Mark R Bannister]

On 16th Dec 2011, 11:37, Jóhann B. Guðmundsson wrote:
> On 12/16/2011 09:26 AM, Mark R Bannister wrote:
> > If this isn't fixed now, in Fedora, then it's likely to cause more pain when it
> > finally reaches RHEL.
> 
> Fedora does not have any bearing on what downstream distribution based 
> on Fedora be it Red Hat or something else do.

<snip>

> I would gestimate that F18+ will become RHEL7

I understand what you're trying to say Johann, but you do sound a little
contradictory!

I sense an attitude of "not my responsibility" here, and a wider problem with the
way that Linux is developed.  Jared told me in this posting
http://lists.fedoraproject.org/pipermail/devel/2011-December/160499.html that
Fedora have practically no sway in upstream development decisions, even those
that affect critical components such as glibc.  Now you're telling me that when
you collectively make decisions about what goes into Fedora, you have no regard
for what the knock-on effect is for downstream, not even how that might impact RHEL.

This would seem to be a disjointed muddle.  Perhaps you can begin to see the
benefit of using Solaris if one vendor can take full responsibility for the whole
thing, rather than trying to run away with as little responsibility as possible.

If a developer makes a change to glibc, he is *absolutely* going to affect RHEL.
 Likewise, by your own admittance that F18+ or thereabouts will become RHEL7, if
a developer makes a change to Fedora, he is *absolutely* going to affect RHEL. 
What benefit could there possibly be for the millions of end users of Linux by
upstream developers burying their heads in the sand or otherwise denying
responsibility for how their actions will affect downstream?  This is the fabric
that makes Linux a success, and will be its downfall if it is not well managed.

<steps off soapbox ...>

Now, back to the original subject matter.  Is backwards compatibility a good
thing, or a bad thing?

> If you cant prepare your infrastructure for these changes and you cant 
> convince upstream then RHEL6 will be supported for years to come.

By your statement "if you can't prepare your infrastructure for these changes
..." it sounds to me like you're happy to be causing pain for system
administrators.  Change is sometimes a necessity, yes, but change for the sake of
change is nothing but a pain.  And in this case, and in my opinion, the nss_db
change in glibc was not required, it benefits no one, and will introduce pain for
no reason.

Best regards,
Mark.