Subject: keeping multiple versions of "library" package runtimes installed
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.org>
From: Greg A. Woods <email@example.com>
Date: 06/10/2007 14:51:36
Content-Type: text/plain; charset=US-ASCII
At Fri, 8 Jun 2007 13:17:40 +0200, Julio M. Merino Vidal wrote:
Subject: Re: emacs22
> On 08/06/2007, at 12:45, Dieter Baron wrote:
> >> This could also be useful to easily split packages providing
> >> libraries into run-time only files (the .so's) and the headers, as
> >> almost any Linux distribution does.
> > I don't see the big benefit in that (and it's something that has
> > annoyed me no end on linux hosts). Header files don't take up much
> > space.
> But they are "ugly" in a production box where you don't want any =20
> compiler-related stuff to be available, for example. Anyway, this is =20
> just a specific use case of this functionality.
Neither disk space nor aesthetics are the issue. Not even a tiny bit.
Please think about binary packages.
Please think about upgrades of a selected few binary packages on a
Please think about systems where not only are applications using library
packages, but the user may also be a developer using some (ANY!) version
of a given library package while at the same time using other
applications which make runtime use of a _different_ version the given
Please consider that header files, in particular, will often have
filesystem namespace clashes between various versions of the same
Please consider that all runtime files (other than .so's) in "library"
packages must all be given ABI-specific pathnames, just like the .so's.
I.e. it must (sooner or later) be possible to have multiple versions of
the runtime files for any and all sub-ordinate (dependant) packages
installed simultaneously (in order to satisfy requirements by other
variously upgraded binary application packages) while still having a
given default "production" version of the same sub-ordinate library
package installed for developer use.
This issue has been in discussion practically since the very first
binary packages from pkgsrc were made available. Let us NOT continue to
sweep it under the carpet as has been done until now.
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
-----END PGP SIGNATURE-----