[arch-general] pacman 4 logic error - what part of 'no' doesn't it understand?
Guys, I have found a logic error in pacman (I think). I don't like replacing both the kernel and kernel-lts in the same 'pacman -Syu' call. So I answered 'no' when prompted to 'Replace kernel26-lts with core/linux-lts? [Y/n] n'. However, then pacman fails to install anything because 'linux-lts and kernel26-lts are in conflict'. When I answered 'n' to Replace kernel26-lts, I expected pacman to ignore upgrading that package (and the others I said no to) but proceed forward and install the remaining updates. Should I file this as a bug? The full output is below: [07:55 archangel:/etc] # pacman -Syu :: Synchronizing package databases... core is up to date extra is up to date community is up to date archlinuxfr is up to date xyne-any is up to date aaany is up to date aapkg is up to date :: Starting full system upgrade... :: Replace kernel26-lts with core/linux-lts? [Y/n] n :: Replace kernel26-lts-headers with core/linux-lts-headers? [Y/n] n :: Replace module-init-tools with core/kmod? [Y/n] y :: Replace perl-exiftool with extra/perl-image-exiftool? [Y/n] resolving dependencies... looking for inter-conflicts... :: linux-lts and kernel26-lts are in conflict. Remove kernel26-lts? [y/N] error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: linux-lts and kernel26-lts are in conflict -- David C. Rankin, J.D.,P.E.
On Wed, Jan 25, 2012 at 12:07 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Guys,
I have found a logic error in pacman (I think). I don't like replacing both the kernel and kernel-lts in the same 'pacman -Syu' call. So I answered 'no' when prompted to 'Replace kernel26-lts with core/linux-lts? [Y/n] n'. However, then pacman fails to install anything because 'linux-lts and kernel26-lts are in conflict'.
When I answered 'n' to Replace kernel26-lts, I expected pacman to ignore upgrading that package (and the others I said no to) but proceed forward and install the remaining updates. Should I file this as a bug? The full output is below:
I think pacman is right. What you asked would make the installation inconsistent: you don't want to replace kernel-lts and will try to install linux-lts, which conflicts with the former. I think you should first use pacman -Syu --ignore linux-lts and, later, pacman -Syu again. That will have the effect you want. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For mor information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On 01/25/2012 08:16 AM, Denis A. Altoé Falqueto wrote:
I think pacman is right. What you asked would make the installation inconsistent: you don't want to replace kernel-lts and will try to install linux-lts, which conflicts with the former. I think you should first use pacman -Syu --ignore linux-lts and, later, pacman -Syu again. That will have the effect you want.
Thanks Altoé, That's what I ended up doing. Looks like it was just the naming convention change that caused the problem. The only 'bug' type behavior was that this was an 'update' so if I didn't have linux-lts installed, why was pacman trying to install it? -- David C. Rankin, J.D.,P.E.
On 01/25/2012 08:07 AM, David C. Rankin wrote:
Guys,
I have found a logic error in pacman (I think). I don't like replacing both the kernel and kernel-lts in the same 'pacman -Syu' call. So I answered 'no' when prompted to 'Replace kernel26-lts with core/linux-lts? [Y/n] n'. However, then pacman fails to install anything because 'linux-lts and kernel26-lts are in conflict'.
When I answered 'n' to Replace kernel26-lts, I expected pacman to ignore upgrading that package (and the others I said no to) but proceed forward and install the remaining updates. Should I file this as a bug? The full output is below:
<snip> I am fairly certain this is due to the kernel/linux naming convention change. Telling pacman to --ignore ignore kernel26-lts,kernel26-lts-headers failed as well, but ignoring kernel26-lts,kernel26-lts-headers,linux-lts,linux-lts-headers did work. Probably not worth a bug report for a 1-off name change, but let me know if you want it filed anyway and I'm happy to do it. The full output of trying the --ignore is provided below: [08:16 archangel:/etc] # pacman -Syu --ignore kernel26-lts,kernel26-lts-headers :: Synchronizing package databases... core is up to date extra is up to date community is up to date archlinuxfr is up to date xyne-any is up to date aaany is up to date aapkg is up to date :: Starting full system upgrade... warning: ignoring package replacement (kernel26-lts-2.6.32.53-1 => linux-lts-3.0.17-2) warning: ignoring package replacement (kernel26-lts-headers-2.6.32.53-1 => linux-lts-headers-3.0.17-2) :: Replace module-init-tools with core/kmod? [Y/n] :: Replace perl-exiftool with extra/perl-image-exiftool? [Y/n] resolving dependencies... looking for inter-conflicts... :: linux-lts and kernel26-lts are in conflict. Remove kernel26-lts? [y/N] error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: linux-lts and kernel26-lts are in conflict -- David C. Rankin, J.D.,P.E.
On Wed, 25 Jan 2012 08:07:10 -0600 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
Guys,
I have found a logic error in pacman (I think). I don't like replacing both the kernel and kernel-lts in the same 'pacman -Syu' call. So I answered 'no' when prompted to 'Replace kernel26-lts with core/linux-lts? [Y/n] n'. However, then pacman fails to install anything because 'linux-lts and kernel26-lts are in conflict'.
When I answered 'n' to Replace kernel26-lts, I expected pacman to ignore upgrading that package (and the others I said no to) but proceed forward and install the remaining updates. Should I file this as a bug? The full output is below:
There is no logic problem here. A full sysupgrade is a non-interactive procedure; the only exception is conflicting packages. What if instead of LTS kernel there was pacman itself? -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Wed, Jan 25, 2012 at 11:55 AM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Wed, 25 Jan 2012 08:07:10 -0600 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
Guys,
I have found a logic error in pacman (I think). I don't like replacing both the kernel and kernel-lts in the same 'pacman -Syu' call. So I answered 'no' when prompted to 'Replace kernel26-lts with core/linux-lts? [Y/n] n'. However, then pacman fails to install anything because 'linux-lts and kernel26-lts are in conflict'.
When I answered 'n' to Replace kernel26-lts, I expected pacman to ignore upgrading that package (and the others I said no to) but proceed forward and install the remaining updates. Should I file this as a bug? The full output is below:
There is no logic problem here. A full sysupgrade is a non-interactive procedure; the only exception is conflicting packages. What if instead of LTS kernel there was pacman itself?
personally i think David's resolution is perfectly reasonable -- denying the upgrade/replacement of a single (or multiple) package does not inherently negate the entire transaction. `-Su` in my mind should try to update everything possible *within the constraints requested*; if skipping the denied package (or --ignore'd, since as he stated that didn't work either) and it's chain of dependencies (and possible reverse dependencies) doesn't break the transaction (which i think in 90% of cases it wouldn't, but it may prevent the update of *many* others), the i don't see a reason why it shouldn't proceed as ordered. when pacman wants to upgrade itself, and the user selects "no", doesn't it still upgrade the system with the old pacman? i've never tried is why i ask ... but TBH, i was under the impression it would behave as i outlined about. if anything, i think pacman could just say something along the lines of "Skipping packages X Y Z will automatically hold back packages A B C, is that acceptable?" -- C Anthony
participants (4)
-
C Anthony Risinger
-
David C. Rankin
-
Denis A. Altoé Falqueto
-
Leonid Isaev