> Nagy Gabor wrote: > > Hi! > > > > http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/universal > > > > I've managed to implement some nice features for -U by "moving" > > upgrade_prepare to sync.c. > > > > 1. Conflict resolving should now work (upgrade051.py now passes), > > FS#3492 implemented. (This was my main motivation.) > > 2. -U --syncdeps now can resolve dependencies by downloading and > > installing them from sync repos. In this case, pacman can skip > > unresolvable targets like with -S. > > > > If this patch is going to be accepted, I ask everyone to test > > "pacman-universal" extensively (there are some changes in UI as well!), > > because sync.c is quite complex, so it has a chance that I broke > > something there (and this is a "radical" change, this is a big > > responsibility). There are no failing pactests, which is a good starting > > point. > > > > I had a quick look at the patches and I like what is done. One part > that confuses me is: > > @@ -460,7 > <http://repo.or.cz/w/pacman-ng.git?a=blob;f=src/pacman/pacman.c;h=1629171ba7d72f2bfef31a9b87ef6a0a94f6ae54;hb=c89b25286ff65ee3e124aa72bcc62f1172740408#l460> > > +462,12 > <http://repo.or.cz/w/pacman-ng.git?a=blob;f=src/pacman/pacman.c;h=690001fe3d16c811b0cfa67b30e48aea0f983403;hb=9d524dd17f557437d61138528ca63f91606437cd#l462> > > @@ static int parseargs(int argc, char *argv[]) > case 'R': config->op = (config->op != PM_OP_MAIN ? 0 > : PM_OP_REMOVE); break; > case 'S': config->op = (config->op != PM_OP_MAIN ? 0 > : PM_OP_SYNC); break; > case 'T': config->op = (config->op != PM_OP_MAIN ? 0 > : PM_OP_DEPTEST); break; > - case 'U': config->op = (config->op != PM_OP_MAIN ? 0 > : PM_OP_UPGRADE); break; > + case 'U': > + config->op = (config->op != PM_OP_MAIN ? 0 : > PM_OP_UPGRADE); > + if(!config->op_u_syncdeps) { > + config->flags |= > PM_TRANS_FLAG_NORESOLVEDEPS; > + } > + break; > case 'V': config->version = 1; break; > case 'b': > config->dbpath = strdup(optarg); > @@ -506,6 > <http://repo.or.cz/w/pacman-ng.git?a=blob;f=src/pacman/pacman.c;h=1629171ba7d72f2bfef31a9b87ef6a0a94f6ae54;hb=c89b25286ff65ee3e124aa72bcc62f1172740408#l506> > > +513,8 > <http://repo.or.cz/w/pacman-ng.git?a=blob;f=src/pacman/pacman.c;h=690001fe3d16c811b0cfa67b30e48aea0f983403;hb=9d524dd17f557437d61138528ca63f91606437cd#l513> > > @@ static int parseargs(int argc, char *argv[]) > } else { > config->flags |= > PM_TRANS_FLAG_RECURSE; > } > + config->op_u_syncdeps = 1; > + config->flags &= ~PM_TRANS_FLAG_NORESOLVEDEPS; > break; > case 't': > config->op_q_unrequired = 1; > > > So the "case U:" part sets PM_TRANS_FLAG_NORESOLVEDEPS by default and > then the "case s:" makes sure it is not set? Or am I reading that wrong > (binary operators and me are not friends...).
-U sets that flag (if -s was not invoked before, this check is because of -sU should do the same), -s unsets that flag. > Would it not be better to use "PM_TRANS_FLAG_RESOLVEDEPS" and then "case > U" stays the same, "case s:" sets it. I suppose that would make the > test in _alpm_sync_prepare more difficult. You are right here, this codepart would look better with PM_TRANS_FLAG_RESOLVEDEPS. I decided to go with NORESOLVEDEPS, because RESOLVEDEPS is the default behavior (for -S), and usually we have a flag for the non-default setting (NODEPS, NOCONFLICTS etc). With RESOLVEDEPS, that flag should be always passed with -S. > Or (my favourite), get rid of this altogether and just assume the deps > are to be resolved by default and expect "-Ud" if someone does not want > that to be done? I can not see a reason someone would not want to sync > deps if there are not already installed and it makes the -U and -S > operations even more universal. Yes, I was also thinking about this, but I decided to keep the old default behaviour as much as possible. [Btw, we have a hidden API change here, alpm front-ends have to pass PM_TRANS_FLAG_NORESOLVEDEPS with -U to keep the old behavior.] If Dan also prefers your way, I will happily implement that (because the code would be nicer, indeed). Bye _______________________________________________ pacman-dev mailing list [email protected] http://www.archlinux.org/mailman/listinfo/pacman-dev
