David O'Brien wrote:
> On Tue, Feb 13, 2001 at 04:24:00PM +0000, Paul RichardsF wrote:
> > When we dropped minor numbers I had a worry that we'd run into one of
> > Windows' greatest problems and we have. Applications that are developed
> > and tested to work with a particular library might not work with a
> > different version,
> How is that???
Because applications expect a stable interface. If an application is
developed and tested against a particular behaviour of a library
function and that function's behaviour is changed it could and sometimes
does break the application. More often than not that sort of failure is
a side effect of *fixing* something that was previously broken.
> It is beter under ELF than a.out in that ld.so isn't making a guess as
> to which shared libs were compatible and which weren't. The ELF ld.so
> does not look for shared lib libxyz.so.2, find libxyz.so.3 and decide
> maybe they are close enough and use it instead. The a.out ld.so would
> use libxyz.so.2.2 when the binary was compiled and tested with
Instead what we have now is libxyz.so.3 and libxyz.so.3 which are
different from each other. When you've got an application that just
broken you've got no way of finding out which version of the library was
the working one, or any way of linking against it because it cannot
co-exist with the newer version because they've got the same name. This
is precisely the problem we've got now.
Maybe I didn't make it clear in my last email, it's not the old a.out
way of picking the library to link with that was better, it was the
finer grained versioning.
> > we're suffering a worst case scenario of this problem
> > now but even "fixes" in new versions can cause applications to break and
> Don't confuse development (which in years past would have never made it
> out of the "company's" development machines, with deployed releases.
This applies to released code as much as in-development code. When you
login to a strange machine and you're trying to diagnose a problem
there's no way to know whether the libc they've got installed is of
version X or version Y because there's nothing to tell you what sources
libc.so.Z was built from, it could be the .Z version with the X fixes or
the Y fixes.
To be honest, DLLs are better than our scheme from that perspective.
While you might screw a load of applications by upgrading a DLL with the
same name you can at least look at the version number in the properties
to find out which version of that DLL it is. There's no way of looking
at a libc.so.5 and say which version of libc.so.5 it is. Although
`ident` does provide a slightly cumbersome way of getting some
information to help with that when you really need it.
> > we've already seen this many times in this iteration of -current.
> *Way*, way too many people are using -CURRENT that have no business doing
I agree with that, I've always been an advocate of raising the barrier
of entry to using -current.
> > I think we need some form of version control on libraries so that
> > applications know whether they're linking with the version they're
> > designed for and to be able to keep multiple versions around in the
> > system so all applications continue to work.
> We have that today and it works very well [in our released product].
> > I understand the reasoning that Elf doesn't need minor numbers but they
> > served an useful purpose in maintaining application compatibility that
> > we now lack.
> NO! Please review the rules ld.so in both ELF and a.out varieties uses
> in finding a desired shared lib.
You've missed the point I was trying to make. Our reluctance to bump
what we perceive to be a major number is hampering our ability to
differentiate between different versions. It has nothing to do with the
difference between a.out and Elf library selection, it's a project
policy problem. We could just as easily use a minor numbering scheme
with Elf to indicate that a version change has occured but not an
interface change. To some extent a three figure version number does
something along those lines.
If we bumped the version number with a bit more abandon this problem
wouldn't even be a problem.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message