Is there a limitation I don't know about in setup.exe dependency checking?

Is there a limitation I don't know about in setup.exe dependency checking?

[Dave Korn]

    Afternoon all,

  Sorry to ask without looking first, but I'm at work and can't stop for long.

  A little experiment I tried during my lunch hour failed on me, and I wonder
if there's something I'm not aware of.  OTOH I could just have bodged the
manual editing I did.

  Because I'm not running upsset, I maually added some lines to setup.ini in
my local mirror, as follows:

[dk@quattro gcc-to-cyg-mirror]$ diff -pu setup-backup/setup.ini ./setup.ini
--- setup-backup/setup.ini      2008-09-08 13:53:21.279050000 +0100
+++ ./setup.ini 2008-09-08 14:33:15.553082000 +0100
@@ -2969,6 +2969,78 @@ version: 3.1.5-3
 install: release/gawk/gawk-3.1.5-3.tar.bz2 1011999
9c2bc45e402eecc3d2cf2db8d04de1bf
 source: release/gawk/gawk-3.1.5-3-src.tar.bz2 1746096
6f85112332957228cc10797780681468
 
+@ gcc4
+sdesc: "GCC Release series 4 compiler (helper for basic C/C++ install)"
+category: Devel
+requires: gcc4-core gcc4-g++
+[test]
+version: 4.3.0-1
+install: release/gcc4/gcc4-4.3.0-1.tar.bz2 1461
52f043fa33436d2d2fe43bbe8dc7292d
+source: release/gcc4/gcc4-4.3.0-1-src.tar.bz2 59546408
ea367e66cbd292e1f93eefadf94cda34
+
+@ gcc4-ada
+sdesc: "GCC Release series 4 compiler: Ada (GNAT) subpackage"
+category: Devel
+requires: cygwin binutils bash w32api gcc4-runtime libgmp3 libmpfr1 gcc4-core
_update-info-dir
+[test]
+version: 4.3.0-1
+install: release/gcc4/gcc4-ada/gcc4-ada-4.3.0-1.tar.bz2 12917330
b856012496cd1028491ad2e882225215
+source: release/gcc4/gcc4-4.3.0-1-src.tar.bz2 59546408
ea367e66cbd292e1f93eefadf94cda34
+
+@ gcc4-core
+sdesc: "GCC Release series 4 compiler: core C compiler subpackage"
+category: Devel
+requires: cygwin binutils bash w32api gcc4-runtime libgmp3 libmpfr1
_update-info-dir
+[test]
+version: 4.3.0-1
+install: release/gcc4/gcc4-core/gcc4-core-4.3.0-1.tar.bz2 9848098
9f335f2e3614b5d66ddf22fbc51ba7e9
+source: release/gcc4/gcc4-4.3.0-1-src.tar.bz2 59546408
ea367e66cbd292e1f93eefadf94cda34
+
+@ gcc-fortran
+sdesc: "GCC Release series 4 compiler: Fortran subpackage"
+category: Devel
+requires: cygwin binutils bash w32api gcc4-runtime libgmp3 libmpfr1 gcc4-core
_update-info-dir
+[test]
+version: 4.3.0-1
+install: release/gcc4/gcc4-fortran/gcc4-fortran-4.3.0-1.tar.bz2 4903271
71c052be6a819d2b5cfbf16b4d66bbb0
+source: release/gcc4/gcc4-4.3.0-1-src.tar.bz2 59546408
ea367e66cbd292e1f93eefadf94cda34
+
+@ gcc-g++
+sdesc: "GCC Release series 4 compiler: G++ subpackage"
+category: Devel
+requires: cygwin binutils w32api gcc4-runtime libgmp3 libmpfr1 gcc4-core
+[test]
+version: 4.3.0-1
+install: release/gcc4/gcc4-g++-/gcc4-g++-4.3.0-1.tar.bz2 6310649
236999bff4801831c769f09b0651aab3
+source: release/gcc4/gcc4-4.3.0-1-src.tar.bz2 59546408
ea367e66cbd292e1f93eefadf94cda34
+
+@ gcc4-java
+sdesc: "GCC Release series 4 compiler: Java subpackage"
+category: Devel
+requires: cygwin binutils bash w32api gcc4-runtime libgmp3 libmpfr1 gcc4-core
_update-info-dir
+[test]
+version: 4.3.0-1
+install: release/gcc4/gcc4-java/gcc4-java-4.3.0-1.tar.bz2 5543233
7be60427c5aa5ff08ccdcf13e6d6b0b4
+source: release/gcc4/gcc4-4.3.0-1-src.tar.bz2 59546408
ea367e66cbd292e1f93eefadf94cda34
+
+@ gcc4-objc
+sdesc: "GCC Release series 4 compiler: ObjC and ObjC++ subpackage"
+category: Devel
+requires: cygwin binutils w32api gcc4-runtime libgmp3 libmpfr1 gcc4-core
+[test]
+version: 4.3.0-1
+install: release/gcc4/gcc4-objc/gcc4-objc-4.3.0-1.tar.bz2 6834411
cbb1c164593cc2223b90d650ff9d7089
+source: release/gcc4/gcc4-4.3.0-1-src.tar.bz2 59546408
ea367e66cbd292e1f93eefadf94cda34
+
+@ gcc4-runtime
+sdesc: "GCC Release series 4 compiler: shared libgcc runtime"
+category: Devel
+requires: cygwin
+[test]
+version: 4.3.0-1
+install: release/gcc4/gcc4-runtime/gcc4-runtime-4.3.0-1.tar.bz2 19975
8c83e8096a1fee5b3dc6d6fd41ec4449
+source: release/gcc4/gcc4-4.3.0-1-src.tar.bz2 59546408
ea367e66cbd292e1f93eefadf94cda34
+
 @ gcc
 sdesc: "C compiler upgrade helper"
 category: Devel
[dk@quattro gcc-to-cyg-mirror]$ 



  I then ran setup.exe and selected the experimental "gcc4" package.  The
"requires:" line for this specifies gcc4-core and gcc4-g++, but neither of
those were automatically selected by clicking "gcc4" to "install" in the
chooser, nor did I get taken to the "missing dependencies, do you want?" page
when I clicked "next"; instead setup.exe just went straight ahead and
installed the (virtually empty) helper-package.

  Knowing that setup.exe doesn't try to hang onto test versions, and
auto-rollbacks them when not specifically set to "skip" (or by using the
"keep" option), I was wondering if this is a side-effect: if there's no "curr"
version of a package that /only/ exists in "test" versions, would setup not
want to trace the dependency?  That is to say, is it not allowed/intended to
satisfy a missing dependency with a "test" version?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Is there a limitation I don't know about in setup.exe dependency checking?

[Brian Dessent]

Dave Korn wrote:

> want to trace the dependency?  That is to say, is it not allowed/intended to
> satisfy a missing dependency with a "test" version?

I think it tries to satisfy the dependency with whatever the current
global trust level is set to.  So if the radio button is on Curr but
there's no Curr version available, it won't do anything.  But if the
radio button is Exp then it should be able to add in Exp versions.  (I'd
have to dig into the code to see whether this is truly the case or
whether it's just hardcoded to Curr only.  I think that's a bug if
true.)

Now admittedly this is really stupid logic.  It should try to match the
trust level of whatever was just selected when adding dependent
packages.

Brian