[ On Monday, May 29, 2000 at 11:54:58 (+0930), Berndt Josef Wulf wrote: ]
> Subject: Re: CVS commit: pkgsrc
>
> Greg A. Woods wrote
> > 
> > However if all packages were statically linked with all non-system
> > libraries then you don't even have to declare any install or runtime
> > dependencies at all in the first place -- just build-time ones.
> 
> Whilst this may be true in case of libraries, it isnt' for
> applications. In my example, most applications will work with any
> version of GS and in this case there is no need of forcing a user to
> upgrade.

True enough.  In some cases you just don't really care which version of
'cat' (or or even 'awk') that you use.  :-)

However if you know you're going to trigger a bug in the related
application unless you use (or do not use) some specific version of an
application (as with XV requiring GS >= 2.6 perhaps).  In those cases it
is just as critical that a package declare run-time (or rather
install-time from the pkg_* point of view) dependencies as it would be
for a dynamically linked package to declare run-time dependencies for
shared libraries.

Of course it's also often possible for applications to directly query
the tools they depend upon at every invocation and make sure the ones
they find are usable versions, just as dynamically linked programs
explicitly specify at least the major release number of the libraries
they use.

This does mean that the pkg maintainer must be held responsible for
encoding the exact same run-time checks into the install-time
dependencies of the package so as to ensure that it will run properly
after being successfully installed.

> Why forcing users to upgrade if older versions work? 

Exactly!  Users should not e forced to upgrade dependant packages until
they are damn good and ready to do so!  ;-)

> I use the example of XV here because it was mentioned in one of the
> earlier postings in respect to ghostscript, but this applies to any
> other package. I believe that it should be the package maintainer's
> responsibility to decide on the revision threshold levels for interdependencies
> on external applications/libraries and not the person updating an
> existing package as it is impossible for anyone to know the
> requirements of all packages affected.

Yes, absolutely.  All I'm saying though is that the package maintainers
have enough work to do without having to become intimate with the often
undocumented APIs (for both C libraries and for command-line and data
output formats) of other packages.  This is a job best left to the
developer(s) and indeed this implies that either the package must always
either explicitly install the correct version of a shared library, *or*
implicitly install it by linking with it statically.

This of course doesn't make the job of integrating packages really any
easier -- to do this right often means fiddling with naming conventions
in order to facilitate simultaneous installation of several releases of
a given dependant package, even if only in the integration environment
where static binaries are built in the case of object-code libraries.
In an ideal world all developers would at least provide all of the
necessary hooks such that several releases of their software could
co-exist simultaneously in both development and production environments.

What static linking does do though is greatly reduce the headaches of
administrators and users who just want to install and *use* packages.
It's one thing to dynamically link against shared *system* libraries and
quite another to do so against add-on libraries that may be considerably
more likely to be upgraded during the life of any given system or group
of related systems.

This problem is of course especially irksome for users who are using the
"current" pkgsrc hierarchy directly to manage packages -- you might want
to just install the new version of "xfig" (for example) that appeared in
the most recent "sup" (or whatever) but you suddenly discover that it
uses a new version of the "jpeg" library and that you'll have to spend a
weeks worth of fetching and compiling in order to update all of the
other packages that depend on the "jpeg" library (six fairly large
applications on my system).  Meanwhile if all package libraries were
installed on pkgsrc development systems with a naming convention that
assured multiple revisions of each could always co-exist, and if all pkg
libraries were always only statically linked, then it would be almost
trivial again to just install that new version of "xfig".  Meanwhile I'm
sure most anyone on any system less speedy than a big beefy 300MHz PII
or similar is sorely tempted to just give up on pkgsrc and install such
packages "in the raw" again (I know I am! ;-).

Of course for final "release" builds of packages who's binaries are cut
onto distribution media to accompany binary releases of NetBSD, it may
make sense for one reason or another (hopefully for space savings and/or
for proven performance reasons only), at least in some cases, to
actually use shared libraries.  If this is the case then I would suggest
that pkgsrc is desperately in need of a configuration flag that allows
shared library builds to be turned on only by someone who knows what
they're getting themselves in for.  Perhaps this kind of feature would
even go so far as to encourage more people to actively use and work upon
the pkgsrc system thus ultimately making the job of current package
maintainers somewhat easier!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>