Dependency changes for ART folks
- 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
- with this option set, we conflicts in versions in dependencies are errors, not overriden
by the higher-level package's version.
#2 Updated by Marc Mengel about 9 years ago
So currently, ups does its product setup matching using two lists in
source:src/upsact.c#L1333 using two variables:
top_list (argument) and
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
((t-upsugo_command*)l_ptr->data)->ugo_productto 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".
#6 Updated by Marc Mengel about 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 almost 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
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 almost 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
- 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..