Re: [PATCH] Postinstall script ordering in setup - take 2

[Robert Collins <rbcollins at cygwin dot com>]

On Wed, 2003-03-05 at 05:13, Igor Pechtchanski wrote:
> Attached is try #2.  This incorporates Rob's comments from
> <http://cygwin.com/ml/cygwin-apps/2003-03/msg00041.html>.  I've also
> refactored FileDesc to handle all dependence processing.

Thankyou. I'll do a proper review tonight (your Changelog passes the
sanity check ;])

> I think this would be good as a long-term solution as well.  As I
> mentioned previously, I don't think we can use the existing package
> dependence mechanism unless we also somehow track which package contains
> which postinstall scripts.  Personally, I think storing dependences in the
> postinstall scripts themselves is cleaner.  Opinions?

I think that package level dependencies is the sensible way *because* we
end up doing it twice using script dependencies.

I.e. if package foo has an install script depending on a script found in
package bar, setup.ini has to list foo requiring bar. Then in the script
we list foo-install requiring bar-utility to have completed first.

Using the packages as dependencies we can build the same topological
tree based on the packages that will end up as installed (Because we do
know which package has which postinstall script).

Re-running install scripts every time, when a package has not changed,
is bad IMO, because we haven't made any requirements for idempotent
behaviour. If a package needs something to occur because it's changed
it, it should trigger that (or, for generics like info pages setup
should observe the occurence and trigger the action).

Any, as I don't have time to complete implementing the dpkg or rpm
behaviour in this regard for setup until the end of the current ice age,
it would be silly to not let in a reasonably implemented alternative.

Thus - I think this is a short term bandaid, because it increases work,
not decreases it, and there is a better solution out there, as shown by
the other package managers.

Rob
-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part