On Fri, 8 Sep 2000, Greg A. Woods wrote:

> [ On Friday, September 8, 2000 at 13:09:36 (-0500), Frederick Bruckman wrote: ]
> > Subject: Re: When DEPENDS can be upgraded in place
> >
> > You're not seriously suggesting that we modify every package to bump
> > it's major version number, every time the author bumps the minor????  
> 
> Well, actually strictly speaking I'm proposing that the major number be
> bumped only every time a "significant" change is made in a package that
> would cause a different shared library binary to be produced.  It's
> irrelevant what the author uses for version identifiers,

No, it's not irrelevant what the author uses. Suppose an author, one
day, decides to support NetBSD, maybe even distribute binaries for it.
He's supposed to maintain a different version number for NetBSD (maybe
for every vendor)? I don't think so.

> If you want new versions of dependent packages to use the new library,
> and if you want to have multiple versions of such libraries installed
> simultaneously then you have to at least change the minor number of the
> library.

I _don't_ want obsolete shared library turds laying around on my
system, but I may be odd man out on this. The problem I have with the
present system, is that an innocuous change to "glib" (perhaps a minor
change to the PLIST), requires me to deinstall and reinstall a couple
dozen packages to test.

> > Please keep the goal of the discussion in mind. We want the package
> > system to accomodate upgrading shared libraries without upgrading the
> > binaries that depend on them, in the _same_ way that you can do that
> > WITHOUT A PACKAGE SYSTEM.
> 
> You just can't do that with impunity in third-party packages, at least
> not those that don't imlement a very standard and well known API.

Gee whiz, thanks for warning me!

> Even bug fixes can introduce more bugs than they fix should the
> users of the broken version have known of the bug and attempted to work
> around it in some way that the fix causes to fail.  The problem is that
> none of the tools we commonly use can detect these kinds of things
> before or at build time.  Even half-baked QA testing won't always catch
> them.  With the number of packages, and the enormous number of
> combinations and permutations possible amongst dependent packages, even
> half-baked QA testing is simply not humanly possible.

So what's the answer? Never upgrade anything? Or only use commercial
software, so you have someone to sue if something goes wrong?

> Note also you're talking about system libraries -- I'm talking about
> pkgsrc libraries.

I'll say just one more thing. Consider, it's been proposed, from time
to time, to "pkgize" the base sets. That would pave the way for a
unified tool for upgrading NetBSD and packages. The chief objection,
and it's a good one, is that with the present system of dependencies,
you'd have to deinstall X and all packages to upgrade the base NetBSD.
Philosophical questions about shared libraries aside, the mechanics of
tracking dependencies for arbitrarily ordered installs is quite
fixable, as I've already proposed.



Frederick