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
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
