Subject: Re: Managing lots of installed packages, buildlink and versions
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-pkg
Date: 05/19/2002 14:12:50
[ On Sunday, May 19, 2002 at 19:09:23 (+0200), Alan Barrett wrote: ]
> Subject: Re: Managing lots of installed packages, buildlink and versions
> I can see why we don't want binary packages built against new versions
> of to be installed with old versions of, but the
> same argument doesn't seem to hold for packages built from sources.  It
> seems to me that it would be reasonable for a binary package to depend
> on *exactly* the version of any shared library packages that it was
> built with, but for the corresponding source package to have much looser
> dependencies.

How do you propose to do that -- i.e. implement a means of allowing
flexible from-source dependencies but sticking to fixed dependencies for
binary packages?  It would seem on first glance that such goals are
diametrically opposed to each other.  How is the pkgsrc infrastructure
to know that someone won't type "make package" after building an
out-of-sync module?

BTW, binary packages do in effect depend on _exactly_ the version of the
shared library that they were built against -- by way of depending on
exactly the version of the dependent package which was present when they
were built.  This implicit fixation of the dependency is provided
courtesy the fact that without Fredrick's proposed package mangling
trick there's no (supported) way to keep a dependent installed while the
library-containing package is upgraded.  Once a consistent set of binary
packages is built and installed you can't install a newer binary of some
package containing a dpended-upon library without de-installing all the
other binary packages which depend on that library, even if the original
pkgsrc modules for those other packages used a relational dependency
which would allow for them to build against a newer library.  Since the
only supported means of building binary packages assumes a fresh start
with a consistent set of pkgsrc modules the person doing the binary
builds will have re-built all the other dependent packages, possibly
upgrading them at the same time.  Therefore the person using the binary
packages will end up being forced to upgrade all the packages which
depend on the shared library being upgraded.

And this is a good thing -- from the point of view of good software hygiene.

People who build only from source can play fast and loose at their own
risk, but such risk must not be allowed to leak into the way binary
packages are managed.  This implicit fixation of dependencies caused by
the pkg_delete/pkg_install operations would better be made explicit, of
course, but from what I can see that would only exacerbate the problems
faced by those who want to play fast and loose with source-only builds
(at least until Fredrick's proposed trick is integrated).

								Greg A. Woods

+1 416 218-0098;  <>;  <>;  <>
Planix, Inc. <>; VE3TCP; Secrets of the Weird <>