What Seriously Ails Fedora

[Gordon Messmer]

On 05/28/2015 04:43 PM, Joe Zeff wrote:
>
> If you are
> maintaining package Foo, which is a dependency of Bar, you have no
> obligation to support Bar.  You do, however, have an obligation to make
> an effort to support backward compatibility in Foo

You're already mixing several different roles into the umbrella of 
"maintaining."

Developers sometimes make incompatible changes.  Sometimes that is 
required to correct a design flaw that cannot be fixed and maintain 
compatibility.  Often it's to add features that can't be done under the 
old design.  In some languages, like C, the developer could bump the 
soname and multiple versions can be installed in parallel.  In other 
languages, there really isn't a provision for versioning.

Packagers just build what developers are publishing.

Fedora is the work, primarily of packagers, not developers.  There are 
instances where I think Fedora's naming scheme is garbage, and parallel 
installation of versioned libraries should be better supported.  boost 
is actually an example.  If I ruled the world, versioned libraries would 
always be named lib<library><version>, such as libboost157.  I think 
Debian names packages that way.  But those packages are not the norm.

For the most part, I think you're blaming the wrong people, and also 
vastly oversimplifying the complexity of maintaining perpetual backward 
compatibility.

And if you disagree, well, one of the advantages of Free Software is 
that you can contribute.  Get involved.  Help provide backward 
compatibility.

> , so that Bar is
> forced to upgrade itself to accommodate changes to Foo.

I'm not sure what you mean.  Bar, in our hypothetical example, is a 
package that doesn't exist any more.  No one is publishing updated 
versions or builds.

> Note, however,
> that listing a specific version of Foo as a a dependency rather than
> having *at least* that version makes all dependency issues caused by
> this a Bar issue, not a Foo issue.

I used boost as my example for a reason.  Each version changes the 
soname.  Compatibility between versions is non-existent.  A package 
cannot depend on boost => 1.53, because boost 1.54 libraries aren't 
compatible.

> B, of course, is an absurd idea, and I doubt that this was an accident.
>   Whoever maintains Foo has the obligation to see to it that any and all
> packages that Foo depends on are listed properly

You started out with an example of Foo, a dependency of Bar, or in other 
words Bar depends on Foo.  You now are talking about things that Foo 
depends on.  Rather than change the relationship you started with, I'm 
going to pretend that you meant that the packages that Bar depends on 
(including Foo) should be "listed properly."

That's already the way the system works.  In fact, that's the problem 
that we're talking about.  When Fedora is upgraded and Bar (or the 
hypothetical boost-terminal) has been dropped from the new release, 
upgrades may fail.  Existing systems may have Bar installed, with its 
dependency on Foo (or boost) noted in the rpm database.  If Foo (or 
boost) in the new release is a new, incompatible version, then the 
upgrade cannot complete successfully.  Either Bar (boost-terminal) will 
be broken, or any new packages that need Foo (boost) will.

Now, if the issue is complex enough to confuse you in discussing how it 
*should* work, can you see how it might be complex enough in practice to 
be a Hard Problem (TM)?