[packman] realcrypt-7.0a-0.pm.2.1.i586 RPM scriptlet/postinstall bugs
matthias.andree at gmx.de
Tue Nov 30 20:17:21 CET 2010
Am 30.11.2010 18:17, schrieb AxelKöllhofer:
> Am Tuesday 30 November 2010 17:04:07 schrieb Matthias Andree:
>> [resending after having subscribed to list]
>> the realcrypt RPM scriptlets don't take upgrading into account, and will
>> deinstall the sudoers/groups after an upgrade with zypper, as though the
>> package had been deinstalled (which it hasn't).
>> Reason is that the scriptlets do not check $1 to figure how many versions
>> of the package are installed.
>> Instructions: <http://fedoraproject.org/wiki/Packaging/ScriptletSnippets>
>> (also apply to openSUSE)
>> IOW, the whole %postun scriptlet should be (note single = here, double ==
>> is an unnecessary non-portable bashism)
>> if [ "$1" = 0 ] ; then
>> # original scriptlet follows
>> echo 'Removing group realcrypt...'
>> /usr/sbin/groupdel realcrypt &>/dev/null || :
>> echo 'Removing entry in /etc/sudoers...'
>> sed -i '/%realcrypt/d' /etc/sudoers
>> # end of original scriptlet
>> The postinstall script seems safe at first superficial glance.
>> (I can correspond in German and English, so pick whatever is conventional
>> for the list.)
> Thanks for the bug report, the issue is "about to be fixed".
> The "about to be" means, that AFAIK the %postun will be run from the package
> previously installed, so one will need two updates until the change takes
> Right now, I checked in a version without any %postun, which should be
> available soon, just to be sure there is no "bad" postun in the installed
> I will check in another package with the fixed %postun in a few days, hoping
> that most users will have received this "intermediate" update by then.
Thanks, that was fast!
Alternatively, you can generally
- post an at (see man at) job to execute after 2 minutes from the new
postinstall script to re-run itself (you'd probably need to package it as
ordinary file, rather than as scriptlet -- at least I don't know how to formally
execute %post scripts explicitly), or
- refuse the upgrade in a %pre[in] script telling the user to deinstall and
reinstall (although I haven't checked what %files then commands with respect to
%config files, if any).
More information about the Packman