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)?
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
