Bug #1923

Dependency changes for ART folks

Added by Marc Mengel over 9 years ago. Updated almost 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Spent time:


They want an option with two parts
  1. with this option set, rather than unsetup a currently setup package, we complain if
    it is setup and not the version we are going to setup
  2. with this option set, we conflicts in versions in dependencies are errors, not overriden
    by the higher-level package's version.


#1 Updated by Marc Mengel over 9 years ago

So the easy part is in upsact_trim_unsetup source:/src/upsact.c#L755 which
currently looks to see what's setup to figure out what to unsetup...

Need to browse the code some more to find the dependency pick-the-highest-one code...

#2 Updated by Marc Mengel over 9 years ago

So currently, ups does its product setup matching using two lists in next_cmd() in
source:src/upsact.c#L1333 using two variables: top_list (argument) and g_prod_done,
where the former is a list of products listed at the top level of the setup (which always
win) and the latter is a list of product names we've setup so far.

The problem is that the g_prod_done list only lists the names of the products that are setup so far; not their version, qualifiers etc. So it looks like we will need to change it to a list of ups_ugo structures which give the setup options of those products, and if a product is already setup, use that list to check for the mismatch. so then

 g_prod_done = upslst_add( g_prod_done, p_act_itm->ugo->ugo_product );

 g_prod_done = upslst_add( g_prod_done, p_act_itm->ugo );

and when we check the list for matching product names, in is_prod_done we use
((t-upsugo_command*)l_ptr->data)->ugo_product to look at the list...

We can test that change, and then try adding some code to check for clashes if
the product is "already done".

#3 Updated by Marc Mengel over 9 years ago

I'm looking at the list of options, it seems -B is available, which sort of fits
for this, as in "Breakproof mode" (or possibly "Bondage and Discipline Dependency mode" :-) )

One could specify it on a setup (or in UPS_OVERRIDE in the environment?)

#4 Updated by Christopher Green over 9 years ago

I'm assuming UPS_OVERRIDE is the environment variable you mentioned Friday but weren't exactly sure of the name?

#5 Updated by Christopher Green over 9 years ago

-B would be fine, but if ups is set up for it I'd be just as happy with a long option only, eg --strict-dependency-versions. Possibly happier, since it doesn't entail trying to come up with and remember a tortured backronym.


#6 Updated by Marc Mengel over 9 years ago

(Chris, ups doesn't currently support any --long options... )

Just checked in a revision that, if given -B on the command line, gives a
(wrong) error if there is a version clash in the dependencies on ups depend.

Still need to
[ ] test with setup as well as depend
[ ] make a proper error message for this case
[ ] add the unsetup/resetup behavior
[ ] add UPS_OVERRIDE code for -B

#7 Updated by Marc Mengel over 9 years ago

Okay so my last analysis of part one was hosey...

It looks like we can get the currently setup verision, etc of product pname
by calling:
t_upsugo_command *setup_ugo_cmd = 0;
setup_ugo_cmd = upsugo_env( pname, g_cmd_info[e_unsetup].valid_opts );

The unsetup checks that are there just look to see if any version of X is setup, and generates the unsetup for it, regardless if it matches.

What we want, is if a version of X is setup that doesn't match the version we have,
we fail, and if the version we want is setup, we don't bother setting it up again. That means we need to pass in the version and qualifiers and check them; or just check the setup version as we go...

#8 Updated by Marc Mengel over 9 years ago

I committed a version into cvs which now appears to do both the checks for:

  • checking for conflicts betweeen branches of the dependency tree
  • checking for conflicts between what's setup already and the product being setup
Still need to
  • put in support for setting this in UPS_OVERRIDE
  • do we want it to fail the toplevel product being setup as well, if it
    conflicts with what is setup (i.e. they have to use unsetup first).

Still need to check carefully , and hopefully add some test cases..

#9 Updated by Marc Mengel over 9 years ago

  • % Done changed from 0 to 70

You can review the net change so far at in the repository to see the main code updates.

#10 Updated by Marc Mengel over 9 years ago

  • % Done changed from 70 to 80

#11 Updated by Marc Mengel almost 4 years ago

  • Status changed from Assigned to Closed

Also available in: Atom PDF