[Rpm-maint] Patch: Add support of syslog when installing/removing packages

Panu Matilainen pmatilai at laiskiainen.org
Thu Mar 3 11:44:51 UTC 2011


On 03/02/2011 04:55 PM, Dexter Morgan wrote:
> On Wed, Mar 2, 2011 at 2:09 AM, Dexter Morgan<dmorganec at gmail.com>  wrote:
>> Hello,
>>
>> i send this patch on the ML to see if this can be merged in mainline.
>>
>> This patch add  support for syslog when installing/removing packages.
>>
>>
>> Feb 27 11:25:51 localhost perl: [RPM] firefox-4.0-0.b12.4.mga1 installed
>> Feb 27 11:25:59 localhost perl: [RPM] firefox-4.0-0.b11.4.mga1 removed
>>
>>
>>
>> Regards,
>> D.Morgan
>>
>
> hi,
>
> here is a new version of the patch that add the support of syslog
> through a config ( %{_use_syslog} ) so people can de activate the
> logging.

No objections to adding syslogging to rpm. In fact its a bit dumb that 
it hasn't done that "always", as that has led to upper level depsolvers 
to each doing it on their own, with the problem that the logs aren't 
reliable since they don't catch things done with rpm itself.

Some (stylistic) issues with the patch though:
- Don't add includes into system.h when the include is only needed in 
one place. The system.h header used to be the junkyard of all the 
includes imaginable but that's not a good practise and it's been cleaned 
up a lot in recent times.
- Me thinks a better place for the logging would be rpmtsProcess() in 
transaction.c, there you can evaluate the macro just once at entry + 
eliminate code and ifdef duplication (either inline of the loop or a 
helper function). Also you can use rpmteType() / rpmteTypeString() to 
get the type of the transaction element instead of manually adding 
"installed" and "removed".
- Perhaps "_transaction_syslog", or something to that effect, might be a 
better name for the macro, as it tells a bit more about what the 
syslogging is used for. Not that it actually makes much of a difference, 
but since the we'll be stuck with the name forever after it's better to 
pay attention to the naming of things :)

	- Panu -


More information about the Rpm-maint mailing list