On Fri, Jan 26, 2001 at 12:15:52PM -0800, Brendan Eich wrote:
> > Speaking as a unix hacker ...
> >
> > Correct versioning on library names (which MS has *never* had)
>
> Really? jband tells me of resource info in DLLs used for versioning.
> blizzard says redhat and others use an ELF section similarly, in
> addition to the poor-man's version-metadata hacked into the filename
> (hey, I'm an old Unix hacker too, filename hacking with versionless
> symlinks suit me).
While the version info *is* there in DLL's, it's not sufficient.
If your program at install time thinks it has all the DLLs it needs, but
then crashes on startup with a DLL versioning error, you're not going to be
very happy.
The same is true on Unix -- rpm and dpkg both check for files, but can't
really check the files' contents. So if the version info isn't in the name,
stuff may install without running but fail to run.
IMHO dependency problems are one of the most evil things that can happen to
any end user, because they're so hard to track down.
IMHO again the only way to deal with this is to have all version information
readily apparent. If your program doesn't run because it can't find
libFoo.so.1.2.3, you know exactly why. But if it crashes on startup due to a
symbol resolution error (or even a rejection of the internal version of the
so), you start second guessing the versions of *everything* you have
installed ... and the problem is suddenly much more complex.
...
Actually, there's an even better reason that the versioning *must* be in the
library name: what if you want to run two programs that depend on different
versions of the shared object? On windows (without those disgusting 8.3 dll
names) you are just SOL -- one program will fail to run, and yell at you
about incorrect versioning.
But on Unix -- hey, i have like 6 versions of every library installed :) and
that's *normal*. It's annoying to have to deal with old programs using old
versions of buggy libraries (since major bugs need to be fixed in old
versions of libraries, especially security-related stuff ... it's
preferrable to have all programs use new library versions, but not always
possible).
It seems to me very likely that Mozilla will fork itself into a stable
version and a devel version sometime after 1.0. For all the pain and
suffering entailed in this approach, it at least gives some consistency. And
if that's the approach, the mozilla shared objects need to have
appropriately versioned names, to allow multiple installs (even if you put
mozilla in separate dirs by version, you need a way to let the linker link
mozilla-dependent programs to the right libraries). But appending 1.0.x,
1.1.x etc etc, i.e. the major-minor-revision numbers of the project as a
whole, to every library, should be just fine (at least in unix). In windows
... I don't know a good way of doing this in windows :) Tell the windows
users to buy Mac OS X.
>
> > is what
> > supposed to prevent this on unix. And it's a system that's worked pretty
> > well.
>
> Versionitis is a downside I've observed, but it comes in wave crests as
> new versions come out, and we hope for long, gentle troughs in which the
> new version suffices for all (upgraded) apps.
Indeed. It takes intelligent planning -- I think the GNOME people do a good
job of that. They choose versions of all system libraries for an
"environment", which is used for a relese of GNOME (eg. the 1.0 environment,
the 1.2 environment). They take great pains to ensure compatibility for all
fixes within an environment. It means that features must sometimes wait for
a new environment version (eg. full antialiasing font support will likely
have to wait for the next GNOME release, which will include Gtk 2). But it
*does* mean that applications have a consistent state across the dozens and
dozens of libraries that GNOME requires ...
ari
