[ On Thursday, June 27, 2002 at 15:24:16 (+0200), Hubert Feyrer wrote: ]
> Subject: Re: make package
>
> Um, what I usually do is:
> 
> 1. make
> 2. pkg_delete (or "make deinstall")
> 3. make install
> 
> This allows having the "old" pkg installed as long as possible, ideally
> until the new one is compile. If there are problems compiling, the old one
> is still there.

Me too, but that only works for trivial scenarios with no run-time
dependents for the package being upgraded.

For example netsaint-plugins depends on ssh.  If your ssh is installed
via a package and you want to upgrade ssh you have to do something like
this, which depends upon knowing/learning the dependencies before you
start: 

	1. cd security/ssh && make
	2. cd net/netsaint-plugins && make
	3. pkg_delete -r ssh
	4. cd security/ssh && make install
	5. cd net/netsaint-plugins && make install

(yes step five alone suffices to replace step 4, but it doesn't really
shorten the time taken unless you don't like typeahead and you type
really slowly, or maybe your computer is so blindingly fast that it can
do the installs in less time than it takes you to hit CR)

(obviously CDPATH=...:/usr/pkgsrc:... is a great benefit! ;-)

now if you know that the ssh dependency in netsaint doesn't require any
libraries, and if you have a binary netsaint-plugins package saved away,
(and you know the ssh command-line API used by netsaint won't change
with the upgrade) then you can avoid having to re-build it from source:

	1. cd security/ssh && make
	2. pkg_delete -r ssh
	3. cd security/ssh && make install
	4. pkg_add /usr/pkgsrc/packages/All/netsaint-plugins*

Both sshd and netsaint really should be stopped before step 3 in each
procedure too, of course...  :-)

Even this is a very simple example.  If libraries are involved, and
especially if libraries for the package being upgraded are involved,
then your only really safe choice is to delete the dependent packages
before you install the new target package, and the re-build all the
dependent packages from source and install them again.  Often this
requires upgrading the dependent packages in step too.  A pedantic
example might be a security flaw in graphics/jpeg where the upgrade
mandates an API change.  If you use any significant number of packages
such an issue could mandate an almost ground-up rebuild of your world.

Now if you've built all your packages with only static linking of other
package libraries then the number of run-time dependencies will be
drastically reduced with static linking, and indeed the complexity and
depth of interdependencies will be almost entierly eliminated (at least
given the currently supported packages). The only remaining run-time
dependencies will be for "command-line" uses of other packages.
Although you really should always upgrade and rebuild any run-time
dependent package every time anyway, you can often get away without
having to do so if you keep binary packages around and if you know the
command-line APIs for the upgraded package haven't changed.
Unfortunately the onus is on the user to check for backwards
compatability in any dependent packages he or she might be using.  The
pkgsrc system does not yet have mechanism (other than the crude
CONFLICTS trick -- and it's rarely, if ever, used that way now) to
prevent an upgraded package from working with an older dependent.

Obviously static linking doesn't solve all security flaws, but it allows
you to attack the problem piecemeal in an order that best suits your own
local risk assesment profile.

(FYI I have a basic framework for static-linking packages and it works
well on the few packages I regularly use, but I don't yet have a simple
way to only provide static libraries from packages while still dynamic
linkining dependent packages with system supplied shared libraries.
Indeed even though I've been static linking all packages on my test
machine, I still sometimes have to allow packages to build and install
shared libraries since modifying them to not do so is a lot of mostly
unnecessary work.)

-- 
								Greg A. Woods

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