Seth Vidal wrote:
%pretans plays all sorts of hell with chroot installs. We tend to
discourage them as much as possible.
Why they are different than %post in chroot?
I guess that there were some implementation problems in rpm, for
example:
https://bugzilla.novell.com/show_bug.cgi?id=235361
Pixel wrote:
Stanislav Brabec [EMAIL PROTECTED] writes:
Using %preun is acceptable only for uninstallation, not for upgrade.
But this is yet another problem mentioned in the document, not related
to one-time-scriptlets.
oops, right. mandriva never went that far :)
Seth Vidal [EMAIL PROTECTED] writes:
On Mon, 16 Jun 2008, Pixel wrote:
However I can imagine an one-time unsubscription counterpart (something,
which will evaluate list of all files going to be removed or overwritten
in the forthcoming transaction and then issue a command with a such
list.
Pixel wrote:
Stanislav Brabec [EMAIL PROTECTED] writes:
Particular problems there may have different severity and different
complexity. The worst one seems to be Problems of Scriptlets / Database
rebuild.
mandriva is currently experimenting something on this subject:
Stanislav Brabec [EMAIL PROTECTED] writes:
[...]
Mandriva patch defines patterns evaluated by RPM runtime.
[...]
* no, install-info is not a good candidate fot this technique,
see http://wiki.rpm.org/Problems_of_Scriptlets (this is an
implementation of Database rebuild, install info
Pixel wrote:
well. more precisely, the patch allows to get rid of %post/%postun,
but not %preun. registration can be handled:
for gconf schema, we've removed the %post and kept the %preun
gconftool-2 --makefile-uninstall-rule on uninstall. The advantage is
doing all --makefile-install-rule
Stanislav Brabec [EMAIL PROTECTED] writes:
[...]
Using %preun is acceptable only for uninstallation, not for upgrade.
But this is yet another problem mentioned in the document, not related
to one-time-scriptlets.
oops, right. mandriva never went that far :)
[...]
However I can imagine an
On Mon, 16 Jun 2008, Pixel wrote:
However I can imagine an one-time unsubscription counterpart (something,
which will evaluate list of all files going to be removed or overwritten
in the forthcoming transaction and then issue a command with a such
list. I think it could be possible to write it
Stanislav Brabec [EMAIL PROTECTED] writes:
Particular problems there may have different severity and different
complexity. The worst one seems to be Problems of Scriptlets / Database
rebuild.
mandriva is currently experimenting something on this subject:
