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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
