[pacman-dev] [PATCH] Cleanup code handling a sysupgrade of pacman itself
Anyone have a problem with this change (Aaron)? -Dan --- The old code attempted to upgrade pacman by itself and automate the process by creating a new transaction and a bunch of other complicated stuff. We should just leave such actions to the user to decide instead of trying to do it for them, and it caused problems when pulling in dependencies. For now, simply request that the user run a 'pacman -S pacman' operation. If they want, they can also answer 'N' at the prompt and the upgrade proceeds as normal. Signed-off-by: Dan McGee <dan@archlinux.org> --- src/pacman/sync.c | 19 +------------------ 1 files changed, 1 insertions(+), 18 deletions(-) diff --git a/src/pacman/sync.c b/src/pacman/sync.c index 8982b95..25563e3 100644 --- a/src/pacman/sync.c +++ b/src/pacman/sync.c @@ -544,24 +544,7 @@ int pacman_sync(alpm_list_t *targets) ":: operation. If you wish to continue the operation and\n" ":: not upgrade pacman seperately, answer no.\n")); if(yesno(_(":: Cancel current operation? [Y/n] "))) { - if(alpm_trans_release() == -1) { - fprintf(stderr, _("error: failed to release transaction (%s)\n"), - alpm_strerror(pm_errno)); - retval = 1; - goto cleanup; - } - if(alpm_trans_init(PM_TRANS_TYPE_SYNC, config->flags, - cb_trans_evt, cb_trans_conv, cb_trans_progress) == -1) { - fprintf(stderr, _("error: failed to init transaction (%s)\n"), - alpm_strerror(pm_errno)); - return(1); - } - if(alpm_trans_addtarget("pacman") == -1) { - fprintf(stderr, _("error: pacman: %s\n"), alpm_strerror(pm_errno)); - retval = 1; - goto cleanup; - } - break; + goto cleanup; } } } -- 1.5.2.1
The main problem I had with this part is the problems it caused during pacman 2 -> pacman 3 upgrade (where pacman got new dependencies, libarchive and libdownload). Apparently, pacman2 first got a list of upgrade and resolved the dependencies, then checked if it was in the target list, and if it was, removed every package but itself from the target list (including its own new dependencies). And then it didn't resolve deps again either. On the other hand, pacman3 first adds the list of upgrade to the targets by calling alpm_trans_sysupgrade, then it checks if pacman is one of them. In this case, it cancels the old transaction and creates a new one with only pacman as target. And only then, it calls alpm_trans_prepare, which will resolve the dependencies. Attaching a pactest which should emulate pacman 2 -> pacman 3 upgrade, but it's now handled fine by pacman3 (not sure this test is very interesting). I let you decide if this behavior of automatically upgrading itself first is needed (apparently, it was in the past). And if it's needed, but you find the code ugly, maybe there are other ways of doing it better ? I personally don't have problems with this part, as it apparently now does its job correctly, but it doesn't mean it's good :)
On 6/13/07, Dan McGee <dpmcgee@gmail.com> wrote:
The old code attempted to upgrade pacman by itself and automate the process by creating a new transaction and a bunch of other complicated stuff. We should just leave such actions to the user to decide instead of trying to do it for them, and it caused problems when pulling in dependencies.
Going through some older mails. Not sure if this was implemented or not, but I always figured pacman should be handled exactly like every other HoldPkg. It makes sense to me. That way an end user has complete control of the warning level for this, AND we don't have weird special case code like this.
On 7/13/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 6/13/07, Dan McGee <dpmcgee@gmail.com> wrote:
The old code attempted to upgrade pacman by itself and automate the process by creating a new transaction and a bunch of other complicated stuff. We should just leave such actions to the user to decide instead of trying to do it for them, and it caused problems when pulling in dependencies.
Going through some older mails. Not sure if this was implemented or not, but I always figured pacman should be handled exactly like every other HoldPkg. It makes sense to me. That way an end user has complete control of the warning level for this, AND we don't have weird special case code like this.
I ended up going back on myself and leaving it as is. To be honest, I'm not sure what special stuff we do for a holdpkg in the code. I'll have to take a look at that. The main thing is pacman will now pull in any required dependencies when upgraded, unlike before when it would not. -Dan
participants (3)
-
Aaron Griffin
-
Dan McGee
-
Xavier