[pacman-dev] My "universal" git repo

[Nagy Gabor]

> 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