[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpmorg-maint
Subject:    [Rpm-maint] [RFC] Move all informative messages to stderr by default (ticket #31)
From:       pmatilai () laiskiainen ! org (Panu Matilainen)
Date:       2016-10-25 14:38:30
Message-ID: 6f2cf273-ae97-f0b1-d03e-30cc815c41de () laiskiainen ! org
[Download RAW message or body]

On 10/25/2016 04:48 PM, Michael Schroeder wrote:
> On Tue, Oct 25, 2016 at 11:20:14AM +0300, Panu Matilainen wrote:
>> On 10/13/2016 09:41 AM, Panu Matilainen wrote:
>>> Rpm has always spewed all sorts of "informative" messages into stdout
>>> where it gets mixed up with user requested information such as query
>>> output, complicating scripts unnecessarily and also breaking unix
>>> traditions.
>>>
>>> Make the user-requested output (namely query and verify output) go to
>>> stdout by explicitly fprintf()'ing it there, and all of rpmlog()
>>> output goes to stderr (or other specified logfile).
>>>
>>> Fixes rpm.org ticket #31, RhBug:1358861, RhBug:247239, RhBug:439290...
>>> OTOH it *will* break scripts people use for querying etc. Making
>>> scripts compatible with both old and new behavior shouldn't be hard, but
>>> it does require changes and some *will* complain. So obviously not
>>> 4.13 material, target would be the next major release after that.
>>>
>>> Comments, thoughts?
>>
>> Ping? No comments at all on a proposal that'd likely break half the scripts
>> created around rpm queries?
>
> What about library users? Seems like they will no longer receive
> the output via the rpmlog callback if you just write to stdout.

For these particular items, yes. The question is does anybody use rpmlog 
callbacks for grabbing query and verify results, or anything at all for 
that matter. I haven't seen a single use in all these years.

There are certainly various other approaches available, but I'd rather 
spend the energy on something else if nobody actually cares about the 
callbacks.

	- Panu -


[prev in list] [next in list] [prev in thread] [next in thread]