Debian Bug report logs - #762467
dpkg: when using --no-act, messages should be shown on stdout, not stderr

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: submit@bugs.debian.org

Subject: dpkg: when using --no-act, messages should be shown on stdout, not stderr

Date: Mon, 22 Sep 2014 18:04:39 +0200 (CEST)

Package: dpkg
Version: 1.17.13

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.

Message #10 received at 762467@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Santiago Vila <sanvila@unex.es>, 762467@bugs.debian.org

Subject: Re: Bug#762467: dpkg: when using --no-act, messages should be shown on stdout, not stderr

Date: Mon, 22 Sep 2014 20:02:19 +0200

Hi!

On Mon, 2014-09-22 at 18:04:39 +0200, Santiago Vila wrote:
> Package: dpkg
> Version: 1.17.13

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

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

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

Message #15 received at 762467@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Guillem Jover <guillem@debian.org>

Cc: 762467@bugs.debian.org

Subject: Re: Bug#762467: dpkg: when using --no-act, messages should be shown on stdout, not stderr

Date: Mon, 22 Sep 2014 22:47:55 +0200

On Mon, Sep 22, 2014 at 08:02:19PM +0200, Guillem Jover wrote:
> > 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".
> 
> 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?

Yes. I think both cases should go to stdout, not only the first one.

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.

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

It is certainly *not* the only difference: In your first example, dpkg
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.

Message #20 received at 762467@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Santiago Vila <sanvila@unex.es>, 762467@bugs.debian.org

Subject: Re: Bug#762467: dpkg: when using --no-act, messages should be shown on stdout, not stderr

Date: Wed, 24 Sep 2014 18:21:11 +0200

Hi!

On Mon, 2014-09-22 at 22:47:55 +0200, Santiago Vila wrote:
> Yes. I think both cases should go to stdout, not only the first one.
> 
> 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

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.

> I naively thought that no 2>%1 would be needed here because of
> the --no-act option, but I was wrong.
> 
> > 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. :)
> 
> It is certainly *not* the only difference: In your first example, dpkg
> 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

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.

> 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? 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

Message #25 received at 762467@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Guillem Jover <guillem@debian.org>, 762467@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#762467: dpkg: when using --no-act, messages should be shown on stdout, not stderr

Date: Thu, 25 Sep 2014 12:08:01 +0200

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.

Send a report that this bug log contains spam.