> We've been providing BRU and BRU Server agents for OpenBSD since 
> OpenBSD 2.8.
> For the most part, OpenBSD updates have not broken compatibility with 
> our baseline builds for 2.8 and 3.5 - until 3.9.  We have a customer 
> that has installed 3.9 on a group of servers and we now witness libc 
> compatibility issues that can't be resolved with a simply symlink.

Sorry, but symlinking shared libraries basically undermines all the
reasons why we change the shared library names.

We specifically change the shared library major/minor numbers because
SEVERE INCOMPATIBILITIES have been introduced, and unlike other
projects we do not feel that these incompatibilities should be shoved
under the rug and ignored, because random people will later get

We introduce the incompatibilities for very strong reasons.  The
commit messages explain things.

> Is it known that applications built against the 3.5 libc are not 
> compatible with 3.9 (they have been proven to work fine with 3.8)?

Yes.  I could research the commits done just before each shared
library revision crank, and write you specific test programs in about
10 seconds for each case.  How will each of those cases affect your
application?  I don't know.  That is why we crank things.

> Is 
> there something that the user can do to enable backwards compatibility, 
> or is the only solution to compile special versions of the BRU tools 
> for 3.9?

There is no binary backwards compatibility.

You have a choice: new or old.  Choose.  I am sorry, but there is no
way we could cope with this any other way as programmers, oh, except
for maybe bloating the code every time we need to change something,
and 10 years from now libc will be a gig.  That's not a world any of
us want.

Noone wants us to stop improving things.

Reply via email to