On Wed, Jan 25, 2012 at 11:55 AM, Leonid Isaev <lisaev@xxxxxxxxxxxx> wrote: > On Wed, 25 Jan 2012 08:07:10 -0600 > "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx> 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
