Ticket #560 (closed defect: fixed)

Opened 11 years ago

Last modified 10 years ago

setup makes poor version choice for dependency product

Reported by: RayPlante Owned by: rhl
Priority: normal Milestone:
Component: eups Keywords:
Cc: bbaker@… Blocked By:
Blocking: Project: LSST
Version Number: 1.1.0
How to repeat:
  • install utils 3.0 as current
  • install utils 3.2
  • install utils from trunk
  • install daf_base 3.2
  • run "setup -v daf_base 3.2". You should see it choosing the trunk version.


Bill and I descovered while he was working on the test builds script that the EUPS setup command was making some unexpected version choices for its dependencies. In our example, daf_base 3.1 had this dependency:

  setupRequired(utils 3.2 [>= 3.2])

The stack already had installed utils 3.0, which was marked current, 3.2, and svn????--a version built from the trunk. When daf_base 3.1 was setup, eups chose utils svn???? as the best version to satisfy the dependency. This caused a build to fail fundamentally because the trunk version was too new---it contained non-backward compatible changes over previous versions. I think that it would have been better if setup had chosen utils 3.2 instead.

I believe that the proper order of preference should be as follows, from most preferred to least preferred:

  1. if the current version satisfies the version criteria, setup the current version
  2. if the explicit, as-built version is available (the version left of the parentheses), that version should be setup.
  3. the latest available version of the package that satisfies the critieria should be setup.

This would provide an environment much more likely to be self-compatible. An even more conservative approach (i.e. more likely to run/build properly) would have (3) above to be the earliest version that satisfies.

Change History

comment:1 Changed 11 years ago by ktl

Part of the problem here is that we cannot automatically detect a break in backward-compatibility. Traditionally, projects use the major version number for this. In our case, the major version (to date) has been co-opted as "DC number".

If we used the major version correctly, ">= 3.2" would imply "< 4.0" and this problem wouldn't have happened.

comment:2 Changed 11 years ago by RayPlante

I'll note that in our particular case, a trunk version was assumed to be more recent than the numbered versions. (That is, I don't think we determine the time-ordered relationship between a numbered release and an svn revision, yes?) In any event, given all this ambiguity, it would be better to prefer the explicit version when it exists over a later version, unless that later version is marked current.

comment:3 Changed 10 years ago by rhl

  • Status changed from new to closed
  • Resolution set to fixed

I thought that I'd closed this; I must have been foiled by a Japanese wirewall.

This is a bug in the eups version ordering, but it's specific to LSST. The solution is to declare that e.g. 3.2 and svnXXXX may not be sorted in the versionCallback defined in the eupsStartup file. This is all implemented in the latest eups r6964 and lssteups r6963, r7102 products.

Note: See TracTickets for help on using tickets.