On Fri Jul 23, 2004 at 04:04:02PM +0000, Matthias Scheler wrote:
> In article <741015589.20040723151348@gmx.net>,
> 	uhel <uhel@gmx.net> writes:
> > Can anyone tell me why pkg_chk at first delets the old packages and then
> > try to build new? If i don't know if i can build a new package or not, i
> > wouldn't delete the old one....
> 
> Because it can't in most cases build the new ones when the old ones are
> still there. Imagine package "foobar-libs" and "foobar-programs" got
> updated. You can't build "foobar-programs" before you've updated the
> "foobar-libs" package. But to do that you need to delete the old version
> of "foobar-libs" and "foobar-programs" first to be able to install
> "foobar-libs".

Interesting point.  I knew there had to be a reason.  But, in the
case of some foobar-libs for foobar-programs, can't foobar-libs be
built and knowing the location of the new libs, foobar-programs includes
that build location for the linker?  runtime should have no problem
once they are both installed, no?  Or for things that need to find
the final destination runtime in order to build, would it be so bad
if both the build path and final pkg path be set?

That would seem like little to pay if the build process could be verified 
with less chance of hosing the system. This is all assuming it could be
done and at the SAs discretion of course.

-- 
Courtney R. Spencer |||