[pacman-dev] pacman --print bug
Hi, I think I found a bug in pacman. When a package remove operation can't be satisfied, pacman prints an error, describes what went wrong, and does nothing: $ sudo pacman -R linux-api-headers checking dependencies... error: failed to prepare transaction (could not satisfy dependencies) :: glibc: removing linux-api-headers breaks dependency 'linux-api-headers>=4.10' This is obviously correct. When I try to --print a package remove operation that can't be satisfied, pacman prints an error, describes it, and does nothing, without printing the targets: $ pacman -Rp linux-api-headers error: failed to prepare transaction (could not satisfy dependencies) :: glibc: removing linux-api-headers breaks dependency 'linux-api-headers>=4.10' I can understand if this is correct behaviour as well, but at a glance it looks strange. When a package remove operation *can* be satisfied, but only with user confirmation (e.g. a HoldPkg was found in target list), pacman will print warnings and ask for user input before deciding whether or not to continue: $ sudo pacman -Rc linux-api-headers checking dependencies... <snip> warning: pacman is designated as a HoldPkg. warning: glibc is designated as a HoldPkg. :: HoldPkg was found in target list. Do you want to continue? [y/N] This is obviously correct. When I try to --print a package remove operation that *can* be satisfied, but only with user input, pacman prints a prompt for input but doesn't wait, and exits immediately, without even printing the warnings: $ pacman -Rcp linux-api-headers :: HoldPkg was found in target list. Do you want to continue? [y/N] This does not sound like correct behaviour to me.
On 8/12/19 10:15 AM, AstroSnail via pacman-dev wrote:
Hi,
I think I found a bug in pacman.
When a package remove operation can't be satisfied, pacman prints an error, describes what went wrong, and does nothing: $ sudo pacman -R linux-api-headers checking dependencies... error: failed to prepare transaction (could not satisfy dependencies) :: glibc: removing linux-api-headers breaks dependency 'linux-api-headers>=4.10' This is obviously correct.
When I try to --print a package remove operation that can't be satisfied, pacman prints an error, describes it, and does nothing, without printing the targets: $ pacman -Rp linux-api-headers error: failed to prepare transaction (could not satisfy dependencies) :: glibc: removing linux-api-headers breaks dependency 'linux-api-headers>=4.10' I can understand if this is correct behaviour as well, but at a glance it looks strange.
When a package remove operation *can* be satisfied, but only with user confirmation (e.g. a HoldPkg was found in target list), pacman will print warnings and ask for user input before deciding whether or not to continue: $ sudo pacman -Rc linux-api-headers checking dependencies... <snip> warning: pacman is designated as a HoldPkg. warning: glibc is designated as a HoldPkg. :: HoldPkg was found in target list. Do you want to continue? [y/N] This is obviously correct.
When I try to --print a package remove operation that *can* be satisfied, but only with user input, pacman prints a prompt for input but doesn't wait, and exits immediately, without even printing the warnings: $ pacman -Rcp linux-api-headers :: HoldPkg was found in target list. Do you want to continue? [y/N] This does not sound like correct behaviour to me.
To add to the inconsistency, if you try to install two packages that conflict with each other, pacman chooses one to prefer, then provides a: warning: removing 'calibre' from target list because it conflicts with 'calibre-git' And installs only the one package. But with the --print option, it prints the filenames of both transactions that it is apparently considering. ... Personally I think there's just a lot of problems with pacman --print, and I think pacutils' pacinstall --print-only does a lot better, as would using expac directly. -- Eli Schwartz Bug Wrangler and Trusted User
On 08/12/19 at 02:15pm, AstroSnail via pacman-dev wrote:
Hi,
I think I found a bug in pacman.
When a package remove operation can't be satisfied, pacman prints an error, describes what went wrong, and does nothing: $ sudo pacman -R linux-api-headers checking dependencies... error: failed to prepare transaction (could not satisfy dependencies) :: glibc: removing linux-api-headers breaks dependency 'linux-api-headers>=4.10' This is obviously correct.
When I try to --print a package remove operation that can't be satisfied, pacman prints an error, describes it, and does nothing, without printing the targets: $ pacman -Rp linux-api-headers error: failed to prepare transaction (could not satisfy dependencies) :: glibc: removing linux-api-headers breaks dependency 'linux-api-headers>=4.10' I can understand if this is correct behaviour as well, but at a glance it looks strange.
When a package remove operation *can* be satisfied, but only with user confirmation (e.g. a HoldPkg was found in target list), pacman will print warnings and ask for user input before deciding whether or not to continue: $ sudo pacman -Rc linux-api-headers checking dependencies... <snip> warning: pacman is designated as a HoldPkg. warning: glibc is designated as a HoldPkg. :: HoldPkg was found in target list. Do you want to continue? [y/N] This is obviously correct.
When I try to --print a package remove operation that *can* be satisfied, but only with user input, pacman prints a prompt for input but doesn't wait, and exits immediately, without even printing the warnings: $ pacman -Rcp linux-api-headers :: HoldPkg was found in target list. Do you want to continue? [y/N] This does not sound like correct behaviour to me.
What would you consider correct behavior?
On Tuesday, August 13, 2019 1:27 AM, Andrew Gregory
What would you consider correct behavior?
I think the simplest changes from current behaviour would be just cosmetic: Failing to prepare for a transaction with --print sounds off. Perhaps just saying dependencies can't be satisfied would be better, though I don't consider this a major problem since it's easy to understand and doesn't stand out very much. The -Rcp example, however, surprised me. I'd consider making the -Rcp example print more like the -Rc example, for one to make it more consistent with -Rp, for two to actually tell the user what the HoldPkgs are. The prompt shouldn't appear, and instead simply say that a HoldPkg was found in the target list.
participants (3)
-
Andrew Gregory
-
AstroSnail
-
Eli Schwartz