Subject: Re: make update hell
To: Nathan J. Williams <>
From: Alistair Crooks <>
List: tech-pkg
Date: 10/15/2004 23:27:04
On Fri, Oct 15, 2004 at 06:13:48PM -0400, Nathan J. Williams wrote:
> Alistair Crooks <> writes:
> > Having said all that about the holistic view, I also believe that
> > package views work perfectly with shared libraries - in fact, that's
> > one area in which I believe they excel.
> pkgviews seems like a decent mechanism for having libfoo1.2 and
> libfoo1.3, but much of the complaint I see in this thread is packages
> demanding libfoo1.3 when they don't need it. In that respect, pkgview
> will make things nicer, but only by papering over the underlying
> problem.

If you mean that the underlying problem is the SONAME that's burned
into the ELF executable using the major version, I'm not sure there's
much that can be done without defining a new linking format, and
migrating everyone (not just NetBSD) to that.  Not that I'd stop in
anyone's way if they did that, but I've enough grey hairs already, and
will be probably have turned up my toes when the ffs clocks roll over.

If you're talking about the open-ended dependency problem in pkgsrc, I
thought we'd fixed that for binary packages when we added the @blddep
stuff to pkg_add, but I see that others are less enamoured with that
recently (although I don't really understand what they're complaining
about).  If it's the open-ended dependency problem when building from
source, well, yes, that's a problem, mitigated by the various
RECOMMENDED defs that we've added.

We've started to record the shared lib "PROVIDES" and "REQUIRES" now
in binary packages, so maybe we can look to use that, and trust to
everyone being good citizens when changing ABIs and major numbers.

And package views make it easier to use different versions of the
shared libraries, since deleting a package from the default view is
simply a removal of a symlink farm.  The package stays where it is, in
the depot, and there's nothing to worry about; the link farm can
easily be recreated if desired.  Binary package maintenance becomes
very cheap.

What do you see as being the underlying problem?