On Thu, Jul 01, 2004 at 11:26:28PM -0400, Greg Hudson wrote:
> It's important to recognize two of Ben's presuppositions from the IRC
> discussion:
>
> (1) He doesn't worry about how our policies and decisions affect
> binary packagers; and
That's really not what I said. I said that I didn't think primary
purpose of our compatibility guarantees was to ensure binary packagers
could ship a binary of a client that links to our library that they'll
always work no matter what. Binary packagers have always had to concern
themselves with stuff like that. Heck, the build of Subversion
TortoiseSVN uses and that our command line binary packages use aren't
even binary compatible because they're built with different tool chains.
Bumping our major to 2, isn't going to resolve that or the bdb, or any
other of these sorts of issues.
I feel that our compatibility guarantees fulfill the following purposes:
a) They serve to let client developers to know when they're going to
have to make source code changes to support the latest versions. They
let the client developers continue to support older versions. But I
don't believe that extends to supporting builds across major version
changes of our *MUTUAL* dependencies.
b) They serve to let users know that upgrading or downgrading isn't
going to break their ability to user a server of a different versions.
That their don't have to dump/reload their repo. That they don't have
to throw away their working copies.
> (2) He doesn't find it important for binary distributions to ensure
> binary compatibility between full releases; for instance, he finds it
> okay that Mandrake doesn't work to ensure that an application built on
> Mandrake 9 will continue to work un-upgraded under Mandrake 10.
Not even from Mandrake 9 to 10, but even between 9.0 and 9.1 for
example. Why? Because Mandrake tries to ship the most current versions
of software. That includes gcc, which routinely changes their ABI. You
can't have binary compatibility AND the latest versions of software. If
for no other reason that binary incompatibilities come from things other
than just libraries changing majors. Some libraries don't even bother
to try and maintain this. Faced with this problem, you can become
Debian and release once every 5 years after you've fixed all the
problems from the authors packages, or you can just punt on the issue.
Toss in a community of people willing to provide binaries built for
multiple versions of their distribution and it's not a big issue.
Due to the amount of difference between every release. Expecting binary
packages built on 9.0 to work on 9.1 is like expecting a binary package
built for RedHat to run on Mandrake. Nevermind expecting 9.0 -> 10.0
binary compatibility which is 3 releases away (they do a 9.0, 9.1, 9.2
and then 10.0, it always follows that format).
> I think these tenets are ruinous if applied across a whole operating
> system. If an operating system is to have a real base of third-party
> applications, it needs to at least try hard to provide binary
> compatibility.
Most 3rd party applications statically link anyway. On IRC you
stipulated that Windows was somehow better in this regard and that's why
it was the predominate desktop. The irony of all this is Windows:
a) Has gone through binary incompatible changes Win16 -> Win32. Though
Win32 ran most Win16 apps.
b) Most apps ship with gobs of DLLs that they install into the System
directory. Which then of course proceeds to break existing applications
that needed different versions.
c) It's a platform where one company controls the API. It isn't put
together from pieces from people all over the world. Or put together by
groups of people who aren't necessarily being paid to do so.
> It's possible that we can get away with sacrificing backward
> compatibility at this relatively early stage because we have so few
> third-party applications built against Subversion. But that's the only
> reason; the fact that the incompatibility comes from a downstream
> dependency is irrelevant.
I don't think it's irrelevant. We can't possibly guarantee binary
compatibility when people start building stuff on what is in essence
different platforms...
If you're going to be shipping binary packages and use shared libraries
you have to know what versions of the shared libraries are on that
system. You have to know the compatibility rules of those libraries.
You have to make sure that what's on your build system is binary
compatible.
Do we expect a Mandrake binary package to run on RedHat? Of course not
the platforms are different. If you go and change a major version of a
library, I don't see how that's any different. Especially considering
some of the reason we don't expect Mandrake packages to run on RedHat is
difference in library versions and other things that affect binary
compatibility.
> Actually, I'd say it's enough to nail down the major versions of
> dependencies *in the default build*. If someone wants to build svn 1.x
> using a --with-apr1 option, that's fine; and if a distribution wants to
> exercise that option because they don't care about binary compatibility,
> that's sad but it's their call.
I'm fine with that. But I have a feeling that we'll end up with a FAQ
on how to build with APR 1.0/Apache 2.2. And I'm really not convinced
we gain a whole lot from that.
> Well, we may be able to compromise on this point by allowing explicit
> configure options to build against the non-specified dependencies.
I'm still trying to parse this sentence. If there's an explicit
configure option how is it a non-specified dependency?
> Regardless, I'd say this pain comes from Apache, with their apparent
> blithe disregard for binary compatibility in httpd. Every time you
> create a new incompatible ABI version, you create pain. We can choose
> to pass that pain on to our direct users in the form of more rigid
> dependency requirement, or onto our third-party developers in the form
> of a poorly-defined ABI.
Ohh come on Greg. I think you're being really unfair to the Apache
people here.
We went through and made gobs of binary incompatible changes right
before we did 1.0. We're planning to make binary incompatible changes
in our 2.0. In fact I think you're the one that suggested most of the
ABI changes that are sitting on that meta issue.
Apache's versioning guidelines say they provide binary compatibility
between releases within the same minor line. APR's say they do within
the same major line. They're both following those rules. Why are you
holding Apache to a higher standard?
I also don't see how your solution of bumping our major relieves the
pain any? Now we have a 2.0 line that is compatible with 1.x working
copies, is compatible with 1.x servers, etc... All along though we've
been telling people that 2.x wouldn't be compatible. That 1.x -> 2.x
might require a dump/load cycle. We'll be overwhelmed with people
asking us all kinds of questions about our compatibility. We'll have
people who want something in our 2.0 that are having problems with APR
1.0/Apache 2.2. Ultimately, I think you'll end up creating more pain
for more people by bumping the major. Especially, since I don't think
this issue is even going to ever become apparent to most of our users.
But you can bet compatibility with their 1.x servers, 1.x wc, etc... is
going to be a concern to them.
> This is quite different. BDB 4.1 vs BDB 4.2 has no effect on the ABI we
> present to applications unless they themselves use BDB, which is rare.
> (If the application still uses BDB, then it may still win depending on
> how clever the linker is, I think.)
Like Apache. Considering it's one of the two servers we have available.
I don't think you can call this "rare". I'd say it's the predominant
one but I don't have any data to prove that.
> Certainly, the lack of data format compatibility between BDB versions is
> one of the reasons why it was a horrible awful brutal mistake to use BDB
> in Subversion. As I'm fond of saying, we built on quicksand, and we've
> seen how our users have suffered as a result. But it's not really an
> ABI issue for us.
That's why I end up helping people who've installed RedHat versions of
Apache over their working Apache packages from David's site, who
suddenly find their repo unaccessible via https?://. They have two
choices to solve it:
1) Rebuild Apache with bdb 4.2.
2) Rebuild Subversion with bdb 4.1.
Maybe technically you're right the bdb ABI doesn't change. But the net
effect that you're making an issue out of is the same. Upgrade
something and it potentially doesn't work. Welcome to real messy world
of dependencies.
I don't think our compatibility guarantees can solve that outside our
limited sphere of influence. We can't control all the variables that
can create binary incompatibilities. What we can do is make users,
binary packagers, and developers using our software/libraries aware of
what we're going to do. When we will and won't be causing a binary
incompatibility. We've done that, APR has done that, Apache has done
that. I think that's enough.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 2 09:51:09 2004