You are not logged in.
I just filed a bug about an optional dep which got closed:
https://bugs.archlinux.org/task/67484
Before posting the issue I checked via "pacman -S notmuch" if it lists optional deps.
It didn't list any. notmuch was already installed.
So now I wonder: why does pacman skip the "optional deps" part when reinstalling a package?
Is this a bug?
Does it skip more steps?
Offline
Why are you reinstalling a package just to check its optdepends? Use -Qi
Offline
So now I wonder: why does pacman skip the "optional deps" part when reinstalling a package?
Is this a bug?
Does it skip more steps?
It doesn't skip the "report optional deps" step when reinstalling them.
The step in question is "report new optional deps", rather than spamming the user on every update each optional dep is only reported on the first package install/update that *adds* it as an optional dep.
As apg pointed out, reinstalling a package is not intended to remind you of its metadata, -Qi exists for that. It's only intended to tell you about relevant new *changes*.
Last edited by eschwartz (2020-08-04 17:35:39)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Why are you reinstalling a package just to check its optdepends? Use -Qi
Because I thought that it shouldn't make a difference?
man pacman doesn't say that reinstalling is handled differently.
Offline
apg wrote:Why are you reinstalling a package just to check its optdepends? Use -Qi
Because I thought that it shouldn't make a difference?
man pacman doesn't say that reinstalling is handled differently.
Oh, I suppose we should put that "behavioral" warning in the section of `man pacman` that currently documents the status message formatting of optdepends on first install?
![]()
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
man pacman doesn't say that reinstalling is handled differently.
man pages are not there to state the obvious.
Offline
fft2000 wrote:apg wrote:Why are you reinstalling a package just to check its optdepends? Use -Qi
Because I thought that it shouldn't make a difference?
man pacman doesn't say that reinstalling is handled differently.Oh, I suppose we should put that "behavioral" warning in the section of `man pacman` that currently documents the status message formatting of optdepends on first install?
install is install in my opinion.
man pacman does not list "first install" or any special handling of optional dependencies.
man pages are not there to state the obvious.
obvious? what is obvious?
How should a user be able to GUESS that side effects might trigger a completely different output?
Really, I am an inexperienced user (don't know the implementation details of pacman) and just thought I did a correct test before filing a bug report.
I thought there could be done SOMETHING to fix/enhance the situation, asked in the forums before filing another report, and the replies are basically "all is fine, you are stupid".
Offline
eschwartz wrote:Oh, I suppose we should put that "behavioral" warning in the section of `man pacman` that currently documents the status message formatting of optdepends on first install?
install is install in my opinion.
man pacman does not list "first install" or any special handling of optional dependencies.
It doesn't list "second install" either. You cannot have special handling if there isn't any normal handling. pacman does not document the format of the informational output it produces.
You're looking for something that doesn't exist. You're relying on your personal understanding of undocumented behavior, and your personal understanding turned out to be wrong.
"man pacman" explicitly documents to use -Qi to determine this information. Please stop complaining that it doesn't document the differences in -S. At this point I'm no longer convinced you made an innocent mistake -- I'm beginning to suspect you're trying to troll us.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
man pages are not there to state the obvious.
obvious? what is obvious?
How should a user be able to GUESS that side effects might trigger a completely different output?Really, I am an inexperienced user (don't know the implementation details of pacman) and just thought I did a correct test before filing a bug report.
I thought there could be done SOMETHING to fix/enhance the situation, asked in the forums before filing another report, and the replies are basically "all is fine, you are stupid".
It should be obvious to anyone, experienced user or not, that reinstalling a package is a fundamentally different operation than installing it.
And don't start whining: no-one called you stupid.
Offline
I am coming from Gentoo and there reinstalls are nothing special, they are even needed from time to time - when dependencies have a binary incompatible change, when USE-Flags change. Even more important: it prints all post-install-messages. That's why I simply expected this to be he case for pacman, too.
pacman is even simpler - it in most cases simply extracts an archive, copies the files into the system and executes some additional post-install-hooks (create initrd, regenerate icon cache, ...).
If the user didn't mess around manually with some files inbetween the outcome should be exactly the same.
I still don't see why reinstalling a package is so fundamentally different. man pages and wiki don't suggest it, either. Sorry for being blind and not seeing the obvious.
This is no trolling, I thought I used a correct method to obtain the info I needed.
Offline
I am coming from Gentoo and there reinstalls are nothing special, they are even needed from time to time - when dependencies have a binary incompatible change, when USE-Flags change. Even more important: it prints all post-install-messages. That's why I simply expected this to be he case for pacman, too.
pacman has post_install() or post_upgrade() scriptlets comparable to ebuild pkg_postinst() for custom functionality, which can do version checks, then echo messages.
The optional dependency notifications, however, are not user-defined post_install() messages. They're provided by pacman's own core and are there to alert you to *changes* in the package metadata which are actionable and you may wish to act on.
pacman is even simpler - it in most cases simply extracts an archive, copies the files into the system and executes some additional post-install-hooks (create initrd, regenerate icon cache, ...).
If the user didn't mess around manually with some files inbetween the outcome should be exactly the same.
You could boil down any package manager to its essentials and describe it as "simple". Say instead that portage, as a source-based ports system, is unusually complicated.
anyway, reinstalling a pacman package *should* be idempotent in terms of the on-disk software. True enough.
But the *log output* when doing so is obviously not going to be identical. The most obvious example is that pacman refers to one as e.g.
:: Processing package changes...
(1/1) upgrading libcapWhile the other is:
:: Processing package changes...
(1/9) installing libeditAnother example is that it doesn't repeat optional dependency notifications that the user was previously informed of.
I still don't see why reinstalling a package is so fundamentally different. man pages and wiki don't suggest it, either. Sorry for being blind and not seeing the obvious.
This is no trolling, I thought I used a correct method to obtain the info I needed.
Again, the man page does not take sides: it doesn't say they're the same, it doesn't say they're different. It doesn't even guarantee optional dependencies will be mentioned at all. But it does say -Qi will provide this info.
I can understand not realizing the correct method of getting the info (even though the manpage *does* say it, anyone can have an oversight and slip up in their reading), but I don't quite understand the argument that "really, -S should show the same".
Anyway, now you know. Is there anything else that needs to be discussed?
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
“Its not a bug, its a feature”
Anyways for those that use ILoveCandy it’s nice to only show relevant information when its actually needed to be shown, it would be really messy if every package just always show all of it’s first install information every darn time!
Let’s enjoy a clean run of the gobbler shall we? ![]()
Offline