Subject: Re: should "make update" check for new version first?
To: Ronald van der Pol <Ronald.vanderPol@rvdp.org>
From: Erik Osheim <email@example.com>
Date: 10/19/2004 15:19:52
On Mon, Oct 18, 2004 at 04:47:36PM +0200, Ronald van der Pol wrote:
> I think the conclusion about "build, 2. deinstall" was that this
> is only possible for the "leaf" package, not for dependancies.
I know this has been discussed repeatedly on this list (and further
that I am not the biggest pkgsrc expert), but thinking about this
problem today I don't understand why this is a problem.
I do realize that if a dependency is rebuilt, that its dependents also
need to be rebuilt.
Here is how things seem to be done currently (as someone said
previously): 1. delete, 2. fetch, 3. build, 4. install. I think build
calls 'make update' recursively on all installed programs that depend
on the software--anyway, calling 'make update' on something like
openssl will cause a lot of packages to get rebuilt because a lot of
packages depend on openssl.
If Y,Z,etc. depend on X, and 'make update' is run on X, here is (AFAIK) what
(X: make update)
1. X: make deinstall
1a. Y: make deinstall
1b. Z: make deinstall
2. X: make fetch
4. X: make install (build first)
4a. Y: make install (possibly fetch, and build first)
4b. Z: make install (possibly fetch, and build first)
Now, manually, I seem to be able to run 'make; make deinstall; make
install' just as easily as 'make deinstall; make; make install' As far
as I can tell, make runs 'fetch' and 'build' and nothing else. So, I
don't understand why this wouldn't work:
(X: make update)
1. X: make fetch
2. X: make
3. X: make deinstall
4. X: make install
(Y: make update)
4a. Y: make
4b. Y: make deinstall
4c. Y: make install
(handle any other Y dependents here as part of the update)
(Z: make update)
4d. Z: make
4e. Z: make deinstall
4f. Z: make install
(handle any other Z dependents here as part of the update)
I'm not a Makefile expert, but functionally, this seems like it would
work (and AFAIK the individual commands do work when done
manually). So, for any given package that was being updated, it would
only try to build if it downloaded the new distfile successfully, and
it would only deinstall if it built successfully. I think this works
well enough recursively, so that it would be feasible.
The one problem I see here is one that seems to already exist in 'make
update'--that things might be built multiple times. I think that the
existing dependency graphing tools could be scripted to optimally
order the list of things to be rebuilt.
Anyway, I apologize for staying on a topic that everyone is sick of,
but after reading documentation and trying some things on my system
(NetBSD 1.6.2 i386 with current pkgsrc) I don't see why this isn't
feasible. Please feel free to respond off-list if you don't feel the
response is relevant to the this, but do want to set me straight.