On Fri, 25 May 2001, Thomas Klausner wrote:

> Mutt made me believe that Frederick Bruckman wrote:
> > In article <20010522093229.BB72DB00B@cvs.netbsd.org>,
> > 	wiz@netbsd.org (Thomas Klausner) writes:
> > > Log Message:
> > > Update dependency on png to >=1.0.11 because of the shlib major bump.
> > > Noted by Frederick Bruckman.
> >
> > Thanks! I think they should all get "nb" bumps, too, the idea being
> > to _not_ overwrite the existing binary packages, to give binary
> > package users a "way out" -- the can stick to the penultimate
> > version(s) of selected packages while the remaining packages are
> > updated a few at a time. If you fail to bump the version after
> > bumping the dependencies, the existing packages will be overwritten,
> > and there will be a huge window where it is not possible to install
> > all of them at the same time (because some will require libpng.so.2
> > and some will require libpng.so.1). That could even make it impossible
> > to install packages that require more than one of these (ghostscript?
> > gnome?) until everything is rebuilt, which would be bad.
>
> I thought a bit about this, and I don't think I really want to do
> this. The main argument I can extract from your statement above is
> that the set of available binary packages should be consistent (and
> I agree with that), but I don't think bumping the version numbers is
> the correct way to achieve this -- rather somebody should build the
> correct binary packages; either for themselves or for upload to
> ftp.netbsd.org.

I don't believe that's good enough. The old packages still exist on
the server, and on the CDROM's, and on people's systems. When folks
say they tried to install "gnome" and it blew up in their faces, are
you going to explain, "Oh, that's because you have imlib-1.9.8.1. You
needed the _other_ imlib-1.9.8.1"?

The end user can never form a rational upgrade plan if you don't bump
version numbers for substantial changes, and changes in dependencies
are substantial changes.

And another thing, let's say someone does decide to upgrade all the
leaves of the png tree on some abysmally slow port. How will they know
which ones to rebuild, if you don't identify them (with nb bumps)?

> If we follow your suggestion to the end, we should just add all the
> majors of all packages one particular package depends on into its
> name...

I suggested nothing of the kind. The obvious problem with changing the
_name_ of a package like imlib is that someone would then be tempted
to wildcard depends on imlib further up the chain (gnome-libs, say),
defeating the whole purpose of changing the name. (See ghostscript and
perl5-#@*!.)

As for the problem that changing the name is supposed to solve -- a
binary package of imlib-1.9.8.1, e.g., would accept a newer png than
it was linked against, because of the fact that the wildcards in the
package are not bounded on the top -- bumping all the versions in step
neatly addresses that, too, because the user can then use "lintpkgsrc
-i" to identify all the packages that need to be upgraded.


Frederick