I fear that this has been the behaviour of dpkg for a long time, but
nevertheless, I think it is a bug and should be fixed.

When I use dpkg --no-act, dpkg shows messages on stderr, and I can't
just do this:

dpkg --no-act --purge somepackage | less

If I tell a program to do something and the program can't do that,
that's an error. In this case, however, I'm merely asking dpkg what he
would do, so the messages are not of the "sorry, I can't do that" type,
but instead "Look, this is what I would do".

For this reason, I believe these messages (and, in general, any program
with --no-act, --dry-run or equivalent options) should be shown on stdout,
as they are not really errors.

If this is not possible by default, please consider adding an
environment variable to achieve this.

Thanks.

Hi!

Could you provide an actual example of the problematic output to know
what do you think is misbehaving? Because if I do this on say fbset, I
get on stdout:

  ,---
  (Reading database ... 219138 files and directories currently installed.)
  Would remove or purge fbset (2.1-28) ...
  `---

but if I do this on dpkg I get something like this on stderr:

  ,---
  dpkg: error processing package dpkg (--purge):
   this is an essential package; it should not be removed
  Errors were encountered while processing:
   dpkg
  `---

Is stuff like that what you perceive as an issue?

For me the only difference between the two is that it's acting the same
except that it does not perform any actual modification (as documented
in the man page), so at least the above two examples make perfect sense
to me. :)

Thanks,
Guillem

In my case, I was trying to determine why apt-get wanted to remove
stellarium today when doing "apt-get dist-upgrade". There was a
message saying

The following packages were automatically installed and are no longer required:
  libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5opengl5 libqt5printsupport5 libqt5qml5
  libqt5quick5 libqt5script5 libqt5sql5 libqt5widgets5 libxcb-render-util0 libxcb-sync1 libxcb-xkb1 libxkbcommon-x11-0
  stellarium-data

so I copied and pasted the list above into a file called "AR" and then
tried to see if I could really remove any of them individually:

for a in `cat AR`; do dpkg --no-act --purge $a; done | less

I naively thought that no 2>%1 would be needed here because of
the --no-act option, but I was wrong.
seems to realize that it is performing a simulation and the wording is
clearly different because of the --no-act option, as it says:

*Would* remove or purge fbset

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.


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).


Thanks.

Hi!

As an aside, you might want to use the same tool that decided those
are not needed anymore, instead of something else which might not
have the exact same world view. For example by using apt options
such as Debug::pkgAutoRemove, maybe Debug::pkgDepCache::Marker or
even Debug::pkgProblemResolver.

Ok, sure, sloppy wording on my side, “… the only _fundamental_ difference
is that it's _trying_ to act …”. There's big chunks of code that are not
even exercised on --no-act, because they depend on database and
filesystem state changes from previous actions.

In the case of the “Would remove or purge pkg” message, it's only
because it needs to bail out early as anything else after that requires
the aforementioned changes to the system. And as the code is checking for
that condition, I guess it was deemed more honest to say what seems to
be going on exactly. But TBH, I've to agree I've always found that to be
slightly inconsistent compared to all other early bail outs. :)

I'll consider reworking that code to remove the inconsistency.

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.

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? Because otherwise, I'm sorry but I'm not seeing myself
going over all relevant error messages and making them conditional (if
possible at all) and changing others to emit conditional sentences, not
even accepting patches in that vein, as that would complicate the code
too much for something that is easily solved with a simple «2>&1».

Thanks,
Guillem

severity 762467 wishlist
thanks

 > I'll consider reworking that code to remove the inconsistency.

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.