severity 762467 wishlist
thanks
> I'll consider reworking that code to remove the inconsistency.
To be consistent, dpkg could similarly say
"Would not remove/purge package foo because it is essential".
without making the alarms sound as if it were the real thing.
That would imply going over any error message and making it
conditional on no-act, which TBH is not very compelling, as mentioned
above I'd rather do the inverse. Or even improve --no-act to try to
exercise more code, although that might require huge amounts of work.
This is somehow a matter of principles: If a program does what you ask
it to do, then there is no error. If dpkg was actually *unable* to
tell me what would happen, that would be indeed an error and using
stderr would be completely justified, but in this case dpkg does what
I ask it to do (i.e. tell me what would happen).
Well, I see it in a different way, for me --no-act is just that, do
not perform modifying actions, to me it does not imply something like
--no-error. If you specify the needed options it will do what was
asked for, as it would w/o --no-act:
,---
$ dpkg --force-remove-essential --force-depends --no-act --purge dash
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: this is an essential package; it should not be removed
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: this is an essential package; it should not be removed
[…]
dpkg: dash: dependency problems, but removing anyway as you requested:
bash depends on dash (>= 0.5.5.1-2.2).
(Reading database ... 219372 files and directories currently installed.)
Would remove or purge dash (0.5.7-4) ...
`---
In any case, would getting rid of the inconsistent message be enough
to satisfy you?
This little inconsistency about the wording is likely worth to be fixed,
yes, but it's not the bug I was reporting here.
The problem is that those messages are treated as errors when they are
actually not.
For example, some programs show their help when you call them with
unknown options. However, when explicitly called with --help, they show
the *same* message, on stdout, and the exit status is 0. There is not a
good reason to show help output (when explicitly asked for) on stderr,
no matter how easy it would be to add 2>&1. This is of course just an
example, but I think it shows that the same message could be an error or
not depending on whether you asked for it or not.
Anyway, I'm downgrading to wishlist, as this does not seem easy to fix.
Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
