rpm lipa

[Jeffrey Johnson]

On Jul 19, 2013, at 12:01 PM, Jeffrey Johnson wrote:

> 
> On Jul 19, 2013, at 11:32 AM, Arkadiusz Miśkiewicz wrote:
> 
>> On Friday 19 of July 2013, Jeffrey Johnson wrote:
>> 
>>> Meanwhile why not just disable the buggy scriptlet
>>> using a rpm cli option and manually erase and reinstall?
>> 
>> You need to know that's the correct way to dealing with this situation. Users 
>> think it's some kind of bug.
>> 
> 
> Busted RPM package because of lack of QA is hardly a new problem.
> 

One last note before I go back to work ...

Triggers were originally implemented to deal with buggy %preun/%postun
scripts.

The vocabulary below comes from /usr/share/doc/rpm-X.Y/triggers

So if a %preun script was "buggy" (the original flaw that led to triggers was
forgetting to test $1 to identify whether upgrade or erase was intended) like
	%preun
	if [ $1= 0 ]; then
	    # this is an erase context
        else
	    # this is an upgrade context
	fi
where the fix is/was to add to a newer upgrade package with
	%triggerun -- ...
	# the new-triggerin scriptlet executes before the buggy old-preun scriptlet

Assuming that the flaw is in a %triggerun script, same analysis applies if %triggerpostun.

A new-triggerin script executes before old-triggerun, and any-triggerun (the new
package is installed, should be in the rpmdb before old-triggerun executes) is
after old-triggerun (which won't help with the assumed old-triggerun bug, but
I note for completeness).

So you SHOULD be able to touch a file in a new-triggerin script to "fix" a missing
file flaw in some packages old-triggerun script.

I still suggest manual intervention as KISS .... and I also believe that
	Provides: notriggerun(foo) <= 1:2-3
is far easier to understand and explain than creating a file by knowing
RPM's state machine.

hth

73 de Jeff