[pacman-dev] [PATCH] Add CheckNewVersion option.

[Xavier]

On Mon, Feb 18, 2008 at 12:33:35AM -0600, Dan McGee wrote:
> On Feb 17, 2008 9:12 AM, Chantry Xavier <shiningxc at gmail.com> wrote:
> > As Nagy previously noted, doing this check on any -S operations might look
> > intrusive, but it can be required.
> > For example, the case where you want to install a package with versioned
> > provisions, using a pacman version which didn't support that feature yet
> > (and there is already a newer pacman in sync db supporting it).
> 
> Hmm, so say I put glibc in my CheckNewVersion option list, and I am
> not running the version in the sync DB. If I were to do this:
> pacman -S mpd
> 
> I would be prompted to upgrade glibc? This seems a bit overreaching,
> as this is exactly what I did today on my server box. :) I would
> prefer it only be invoked on a --sysupgrade operation. But you do have
> a valid point.
> 

In this case, you would not put glibc in that option list.

And well, if there are situations where you would like to see glibc upgraded
first, and others where you would not, you just to answer yes or no to
pacman's question. It's interactive and you can choose the path you want.

To have only glibc in that option list might be dangerous, if the newer glibc
is incompatible with the current pacman. But if both pacman and glibc are
there, it should be fine I think.

> I'm also not sure about "CheckNewVersion" from a naming standpoint.
> Maybe something more like "UpgradeFirst" or something? We check for a
> new version of every package, so the name seems a bit misleading.
> 

CheckNewVersion seemed alright, but UpgradeFirst looks better and more
explicit about what it does, I will use that name everywhere.

> >         if(needs_transaction()) {
> > -               if(sync_trans(targets) == 1) {
> > +               alpm_list_t *targs = alpm_list_strdup(targets);
> > +               if(!(config->flags & (PM_TRANS_FLAG_DOWNLOADONLY | PM_TRANS_FLAG_PRINTURIS))) {
> 
> Presumably could just add a check for config->op_s_upgrade here. I
> just don't know that it makes sense to honor this variable for all -S
> ops and not just -Su.
> 

Indeed, it would be easy to do that here. But you didn't convince me with
your previous glibc argument.
Besides, as you just said, we just need to add a simple check to change this
behavior, so it could always be done later if it's really needed :)