Bugzilla – Bug 1041742
transfiletriggerin and transfiletriggerpostun are not executed by libzypp
Last modified: 2023-11-24 16:40:02 UTC
In GNOME:Next, we started experimenting with file triggers (with the goal to lower the number of bugs based on missing post scripts) As a sample, I implemented this trigger (on glib2-tools): %transfiletriggerin -n glib2-tools -- %{_datadir}/glib-2.0/schemas %{_bindir}/glib-compile-schemas %{_datadir}/glib-2.0/schemas %transfiletriggerpostun -n glib2-tools -- %{_datadir}/glib-2.0/schemas %{_bindir}/glib-compile-schemas %{_datadir}/glib-2.0/schemas The trigger is confirmed to work, but in some cases, it seems not to fire, eg on the package 'gdm' (which is currently the reason why http://download.opensuse.org/repositories/GNOME:/Medias/images/iso/?P=GNOME_Next*.iso fails to boot to desktop) zypper in --no-recommends gdm => the file trigger is not executed rpm -i gdm-3.24.1.rpm => the trigger actually seems to work (which is why I file it against libzypp) This currently stops us from moving forward and proposing file triggers to be more widely used (even though I think they can solve quite some packaging bugs) The packages in question for testing are all in the GNOME:Next repository (glib2 which has the trigger, it has the %glib2_gsettings_schema_post set to %nil, so packages that use it in their post script only get a dummy - once the implementation is complete, we will of course go and clean those out completely)
(In reply to Dominique Leuenberger from comment #0) > zypper in --no-recommends gdm => the file trigger is not executed > rpm -i gdm-3.24.1.rpm => the trigger actually seems to work (which > is why I file it against libzypp) If a package contains a %posttrans script, zypp passes '--noposttrans' to the rpm install command. Maybe this disturbs? I don't know what else in libzypp could influence this, as we don't use librpm, but exec 'rpm' to install the package. The exact rpm command is visible in the zypper.log (grep "Executing 'rpm'" /var/log/zypper.log).
(In reply to Michael Andres from comment #1) > (In reply to Dominique Leuenberger from comment #0) > > zypper in --no-recommends gdm => the file trigger is not executed > > rpm -i gdm-3.24.1.rpm => the trigger actually seems to work (which > > is why I file it against libzypp) > > If a package contains a %posttrans script, zypp passes '--noposttrans' to > the rpm install command. Maybe this disturbs? I don't know what else in > libzypp could influence this, as we don't use librpm, but exec 'rpm' to > install the package. > > The exact rpm command is visible in the zypper.log (grep "Executing 'rpm'" > /var/log/zypper.log). ok, so gdm having a posttrans might indeed be the reason that rpm also skips the transfiletriggerin - which is, after all, also a post-trans script I'll do some tests on my VM to confirm that this is indeed the case when using rpm.. and if so, we need to find a solution
Confirmed: rpm --noposttrans actually also skips the transaction file triggers
@mls: is there a way to circumvent this? But even if, we still face the fact that every package forms it's own transaction. So %transfiletrigger will behave more or less the same as a %filetrigger.
Do those need to be transfiletriggers? I very much dislike posttrans scriptlets, that would include those triggers as well ;)
Maybe in context of libzypp there is not much difference between transaction and packages - but generally seen, it's really bad having to start some cache updater 250 times instead of once.
(In reply to Dominique Leuenberger from comment #6) > Maybe in context of libzypp there is not much difference between transaction > and packages - but generally seen, it's really bad having to start some > cache updater 250 times instead of once. Most packages solve this via %posttrans. Libzypp uses '--noposttrans' as we manually collect the posttrans scripts and execute them after _all_ packages were installed. But we can't do this for filetriggers.
In this case we need a way to clearly make sure that transfiletriggers are NOT supported in openSUSE - making clear what sideffects / errors it will have. Preferably rpmbuild will fail on a .spec file with a transfiletrigger linking to the doc )or we will get fun bug reports at one time - just like this one)
@mls: Isn't it actually a bug in rpm, that --noposttrans not just disables the %posttrans as it should, but also the triggers?
it seems to disable the posttrans file triggers. Dunno if that can be consifered a bug.
> --noscripts > --nopre > --nopost > --nopreun > --nopostun > --nopretrans > --noposttrans > Don't execute the scriptlet of the same name. The --noscripts > option is equivalent to > > --nopre --nopost --nopreun --nopostun --nopretrans --noposttrans > > and turns off the execution of the corresponding %pre, %post, %preun, > %postun %pretrans, and %posttrans scriptlet(s). The manpage says nothing about disabling triggers. Do --nopost/--nopostun also disable the corresponding triggers?
@mls: Leaving it up to you. A bug to fix or WONTFIX?
This needs an answer and a fix or documentation to avoid wasting time on something that is know to fail.
(In reply to Michael Andres from comment #12) > @mls: Leaving it up to you. A bug to fix or WONTFIX? Can we please solve this with as *working* solution ... compare with boo#1152105 and SR#713226 Those %filetranstriggerin / %transfiletriggerun are perfect to reduce time on enabling info nad manual pages without using cron or time consuming single calls
As well as SR#733634
Correct maintainer for libzypp to get a working solution
The tracker bug boo#1133764 ... with subject: [TRACKER] port packages to use file triggers can not be done without working libzypp
This is an autogenerated message for OBS integration: This bug (1041742) was mentioned in https://build.opensuse.org/request/show/733658 Factory / texinfo
- Without fixing rpm, %transfiletrigger* will not be executed because --noposttrans also disables the %transfiletrigger in rpm. - Even if rpm would be fixed and would execute %transfiletrigger, they will behave the same way as if you use ordinary %filetrigger* due to the way we use rpm. Workaround could be to use %filetrigger to touch some indicator file and a posttrans rebuilding the cache if the indicator file exists. This should work no matter if rpm gets fixed or not.
(No matter whom it is assigned to) @mls: Can we have an option to let rpm execute the %transfiletrigger even if --noposttrans is passed?
Any updates on this?
@mls: ? (see comment#20)
FWIW systemd needs this feature too so many heavy actions would be executed only once during system updates, see [1] for details. [1] https://github.com/systemd/systemd/blob/master/src/core/triggers.systemd.in
JFYI: SR#883228 brings rpm-4.16.1.3 to factory (mls: also as MR to SLE/Leap15.x ?) With this rpm being installed we hope to be able to resolve the issue (most probably in libzypp-17.26.1). With older rpm versions installed the current behavior remains unchanged...
This is an autogenerated message for OBS integration: This bug (1041742) was mentioned in https://build.opensuse.org/request/show/910984 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910985 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910986 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910987 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910988 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910989 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910990 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910991 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910992 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910993 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910994 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910995 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910996 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910997 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910998 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/910999 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/911000 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/911001 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/911002 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/911003 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/911004 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/911005 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/911006 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt https://build.opensuse.org/request/show/911007 Backports:SLE-15-SP3 / rubygem-bcrypt_pbkdf-1.1+rubygem-childprocess-4.1+rubygem-erubi-1.10+rubygem-i18n-1.8+rubygem-listen-3.6+rubygem-mime-types-3.3+rubygem-net-scp-3.0+rubygem-net-sftp-3.0+rubygem-net-ssh-6.1+rubygem-rake-13.0+rubygem-rb-fsevent-0.11+rubygem-rexml-3.2+rubygem-rspec-3.10+rubygem-rspec-core-3.10+rubygem-rspec-expectations-3.10+rubygem-rspec-mocks-3.10+rubygem-rspec-support-3.10+rubygem-vagrant_cloud-3.0+rubygem-webrick-1.7+rubygem-winrm-2.3+rubygem-winrm-elevated-1.2+rubygem-winrm-fs-1.3+vagrant+vagrant-libvirt
I've tested here on my Tumbleweed system, using a dummy package to echo output messages. It's working for transfiletriggerin but, sadly, it gets invoked way too frequently IMO. In a DUP transaction with 377 updates, transfiletriggerin got invoked around 76 times. And transfiletriggerpostun still no joy. > $ rpm -q rpm > rpm-4.17.1.1-2.1.x86_64
(In reply to Luciano Santos from comment #28) > I've tested here on my Tumbleweed system, using a dummy package to echo Please try also with the new installer backend. It should behave much better than the old one. Especially regarding thrigers. Enable it by calling `ZYPP_SINGLE_RPMTRANS=1 zypper ...` Or persistently enable it in /etc/zypp/zypp.conf's [main] section by setting [main] techpreview.ZYPP_SINGLE_RPMTRANS=1
(In reply to Michael Andres from comment #29) > (In reply to Luciano Santos from comment #28) > > I've tested here on my Tumbleweed system, using a dummy package to echo > > Please try also with the new installer backend. It should behave much better > than the old one. Especially regarding thrigers. Enable it by calling > `ZYPP_SINGLE_RPMTRANS=1 zypper ...` Or persistently enable it in > /etc/zypp/zypp.conf's [main] section by setting > [main] > techpreview.ZYPP_SINGLE_RPMTRANS=1 Alright, with this new installer backend, things got much better. In a DUP with 114 updates, tranfiletrigger(in|postun) is invoked only once (and I think that in my previous test I messed up the transfiletriggerpostun scriptlet, thus it didn't run). And I saw that, apparently, Zypper is converting filetriggers to triggers. I'm going to keep an eye on the next DUPs.
(In reply to Luciano Santos from comment #30) > And I saw that, apparently, Zypper is converting filetriggers to triggers. > I'm going to keep an eye on the next DUPs. The new backend is purely driven by librpm, so such a conversion would be done by rpm. But it could also be a matter of our reporting. If you find an issues, please try to provide a small screenshot or description and please attach the /var/log/zypper.log so we can investigate. Thanks.
I was hoping to be able to use %transfiletriggerun to solve bug 1195291 (on SLE/Leap). This bug here would prevent that solution. (In reply to Michael Andres from comment #7) > Most packages solve this via %posttrans. Libzypp uses '--noposttrans' as we > manually collect the posttrans scripts and execute them after _all_ packages > were installed. But we can't do this for filetriggers. Why not?
(In reply to Martin Wilck from comment #32) > Why not? There were no options to prevent rpm from executing the triggers and for libzypp to query the triggers and to compute which triggers would have been executed, if all packages would have been executed in a single rpm transaction. That's why we implemented an install mode that uses a single transaction completely driven by rpm. Posttrans OTOH is comparably easy because we can query the script and there is no condition(trigger) tied to it's execution. ZYPP_SINGLE_RPMTRANS should be propagated and established as new default. Even for SLE/Leap. Amending the traditional install would meanwhile be possible by using a patched rpm. But this is not yet tested and it bears a high risk to break existing packages and workflows. All trigger scripts would move to different locations within the whole transaction. This may break things and if this happens at the customers side there is no fallback. Unlike a rpm transaction, which can not be interrupted by Ctrl-C e.g., the traditional installer can be interrupted between packages. In some modes (downloas-as-needed) it even performs alternating downloads and installs. So we would not even be able to offer the 'fix' in all modes. Not talking about of all the risks when having to recover from an error within the install. SINGLE_RPMTRANS solves all this 'for free'. With ZYPP_SINGLE_RPMTRANS we have the mode we'd like to harden and establish as future default. It has different prereqs and behaviour, for example enforcing download in advance, not being interruptible. Even if you'd kill zypper/YAST, the rpm transaction will continue like rpm itself would. The traditions install could stay as fallback if actually needed somwhere. If we try to offer some solution for the traditional install, it would be a 3rd workflow somewhere in the middle of the above two. Something half-baked. Our goal is to get rid of the traditional install, and not to maintain 2 install favors. That's why we made SINGLE_RPMTRANS availabkle in whole SLE-15 (GA-SP5).
https://build.opensuse.org/request/show/1080134 Will this work as expected, i. e. restarts php-fpm as soon as any extension rpm touches a shared object under %{extension_dir}/? See also bug#1210576.
(In reply to Petr Gajdos from comment #35) > https://build.opensuse.org/request/show/1080134 > > Will this work as expected, i. e. restarts php-fpm as soon as any extension > rpm touches a shared object under %{extension_dir}/? > > See also bug#1210576. See c#33. Only new ZYPP_SINGLE_RPMTRANS backend handles %transfiletriger as expected. In the traditional backend they behave more like ordinary %filetrigger.
(In reply to Petr Gajdos from comment #35) > https://build.opensuse.org/request/show/1080134 > > Will this work as expected, i. e. restarts php-fpm as soon as any extension > rpm touches a shared object under %{extension_dir}/? > > See also bug#1210576. If it works, it's nice, if not, nothing is lost. Until now, the php-fpm.service wouldn't be restarted if one or more extensions were updated at all. Only when php-fpm would be updated at the same time, the %posttrans would make sure that php-fpm.service would be restarted once more after all packages were installed/upgraded/removed. This to prevent the situation where the update of the php-fpm package would happen before the update of the extensions, so it would be restarted 'too soon' in that case and needed an additional restart. The %transfiletriggerpostun seems to do the job for me, although I already use ZYPP_SINGLE_RPMTRANS for a while, so this behave differently on systems without this.
(In reply to Michael Andres from comment #36) > See c#33. Only new ZYPP_SINGLE_RPMTRANS backend handles %transfiletriger as > expected. In the traditional backend they behave more like ordinary > %filetrigger. Just out of curiosity, for how long will this backend still be considered as an experimental feature ?
(In reply to Arjen de Korte from comment #37) > (In reply to Petr Gajdos from comment #35) > > https://build.opensuse.org/request/show/1080134 > If it works, it's nice, if not, nothing is lost. [..] > The %transfiletriggerpostun seems to do the job for me, although I already > use ZYPP_SINGLE_RPMTRANS for a while, so this behave differently on systems > without this. As far as I tested the above change means that in case you are updating N php extensions (generated from the php8 package) in one zypper transaction e. g. with zypper up to newer php version, then the php-fpm is restarted N times. With ZYPP_SINGLE_RPMTRANS=1 it seems to work better, yes.
(In reply to Petr Gajdos from comment #39) > (In reply to Arjen de Korte from comment #37) > > (In reply to Petr Gajdos from comment #35) > > > https://build.opensuse.org/request/show/1080134 > > > If it works, it's nice, if not, nothing is lost. > [..] > > The %transfiletriggerpostun seems to do the job for me, although I already > > use ZYPP_SINGLE_RPMTRANS for a while, so this behave differently on systems > > without this. > > As far as I tested the above change means that in case you are updating N > php extensions (generated from the php8 package) in one zypper transaction > e. g. with zypper up to newer php version, then the php-fpm is restarted N > times. With ZYPP_SINGLE_RPMTRANS=1 it seems to work better, yes. Restarting N times is not good, so this means we should either forget about this or check if ZYPP_SINGLE_RPMTRANS is set.
(In reply to Franck Bui from comment #38) > (In reply to Michael Andres from comment #36) > > See c#33. Only new ZYPP_SINGLE_RPMTRANS backend handles %transfiletriger as > > expected. In the traditional backend they behave more like ordinary > > %filetrigger. > > Just out of curiosity, for how long will this backend still be considered as > an experimental feature ? I am interested in answer to this question, too. By the way: why I see ZYPP_SINGLE_RPMTRANS form %posttrans but not from %transfiletriger?
Am I correct in my observation that YaST in Tumbleweed doesn't honor ZYPP_SINGLE_RPMTRANS=1? It looks like YaST treats %transfiletrigger* as %filetrigger* regardless of this setting. This is quite detrimental if this is used to restart a service, as one will quickly run into the following problem: Apr 30 15:21:21 example systemd[1]: php-fpm.service: Start request repeated too quickly. Apr 30 15:21:21 example systemd[1]: php-fpm.service: Failed with result 'start-limit-hit'. Apr 30 15:21:21 example systemd[1]: Failed to start The PHP FastCGI Process Manager. After that, the service that was previously running no longer is. This is even worse than not restarting the service at all.
This is an autogenerated message for OBS integration: This bug (1041742) was mentioned in https://build.opensuse.org/request/show/1085752 Factory / systemd
This is an autogenerated message for OBS integration: This bug (1041742) was mentioned in https://build.opensuse.org/request/show/1088562 Factory / systemd
The next libzypp-17.31.21 (will be released during this week) together with rpm-4.17.0 (on TW) will execute %transfiletriggerpostun and %transfiletriggerin at their correct location with both backends. Also the %transfiletrigger will not be lost if the package also has a %posttrans. For Code15 rpm there would need to be updated or the '_dump_posttrans / --runposttrans' feature be backported to rpm-4.14.
Those are wonderful news, I suppose we'll have to wait a bit longer to benefit from all that hard work yet, but that's no big deal. P.S.: I think you meant RPM 4.19 (which is still RC1, right now [1]) 1. http://rpm.org/timeline
(In reply to Luciano Santos from comment #47) > I suppose we'll have to wait a bit longer Unfortunatey, yes. I'm about to do the final tests. With libzypp-17.31.21 and our rpm>=4.17 on TW both backends (incl. YAST and PK) will execute the %transfiletrigger(postun|in) correctly. With rpms not supporting 'rpm --runposttrans FILE', the traditional backend will behave as it currently does. > P.S.: I think you meant RPM 4.19 (which is still RC1, right now [1]) No. The --runposttrans option is SUSE specific (since 4.17) an AFAIK not available upstream.
Oh, now I see what you meant. Thanks for the clarification. And I find it comforting to know that things will work out even without ZYPP_SINGLE_RPMTRANS=1. I tested that for a while, but switched back because the memory consumption of a single RPM transaction would go high compared to the usual approach, I can't say whether that changed nowadays, though.
https://github.com/openSUSE/libzypp/pull/485
(In reply to Michael Andres from comment #46) > For Code15 rpm there would need to be updated or the '_dump_posttrans / > --runposttrans' feature be backported to rpm-4.14. Sorry but I can't parse that. Could you rephrase it ? Also can we make sure that ALP will be fixed too ? Thanks.
(In reply to Franck Bui from comment #51) > (In reply to Michael Andres from comment #46) > > For Code15 rpm there would need to be updated or the '_dump_posttrans / > > --runposttrans' feature be backported to rpm-4.14. > > Sorry but I can't parse that. Could you rephrase it ? Sorry for the bad wording. The fix will require 2 things: a) libzypp-17.31.21 (able to use 'rpm --runposttrans') b) A rpm patch to support the --runposttrans option (a) libzypp-17.x will be available in TW and Code15 (i.e. in TW/ALP and all maintained SLE/Leap 15.x distros). (b) AFAIK currently only TW/ALP contain such a rpm version: # zypper tos Distribution Label: openSUSE Tumbleweed # rpm --version RPM version 4.18.0 # rpm --runposttrans rpm: need posttrans manifest for --runposttrans Code15 still uses rpm-4.14 without the patch: # zypper tos Distribution Label: openSUSE Leap 15.5 # rpm --version RPM version 4.14.3 # rpm --runposttrans rpm: --runposttrans: unknown option > Also can we make sure that ALP will be fixed too ? AFAIKS ALP uses the TW versions, so it should have the fix as soon as libzypp-17.31.21 is submitted.
Thanks for the clarification. (In reply to Michael Andres from comment #52) > > Also can we make sure that ALP will be fixed too ? > AFAIKS ALP uses the TW versions, so it should have the fix as soon as > libzypp-17.31.21 is submitted. AFAIK, you'll need to submit the changes to ALP manually now as the automatic submission process has stopped since a couple of weeks already.
Fixed in libzypp-17.31.21 if rpm supports --runposttrans (rpm-4.17).
*** Bug 1212798 has been marked as a duplicate of this bug. ***
JFYI: bug#1216091 indicates that 'rpm --runposttrans' does not respect '--root' when executing the scripts. We'll have to disable it until rpm's fixed.
Apparently the chrooted script execution broke in one of the rpm-4.18 updates. We disable the 'rpm --runposttrans' usage (iff --root is used) until rpm-4.19, where the issue should be fixed.
This is an autogenerated message for OBS integration: This bug (1041742) was mentioned in https://build.opensuse.org/request/show/1119192 Factory / systemd
SUSE-RU-2023:4536-1: An update that has five fixes can now be installed. Category: recommended (moderate) Bug References: 1041742, 1203760, 1212422, 1215979, 1216091 Sources used: SUSE Linux Enterprise Server 15 SP1 (src): libzypp-17.31.22-150100.3.120.1 SUSE Linux Enterprise High Performance Computing 15 SP1 LTSS 15-SP1 (src): libzypp-17.31.22-150100.3.120.1, zypper-1.14.66-150100.3.90.1 SUSE Linux Enterprise Server 15 SP1 LTSS 15-SP1 (src): libzypp-17.31.22-150100.3.120.1, zypper-1.14.66-150100.3.90.1 SUSE Linux Enterprise Server for SAP Applications 15 SP1 (src): libzypp-17.31.22-150100.3.120.1, zypper-1.14.66-150100.3.90.1 SUSE CaaS Platform 4.0 (src): libzypp-17.31.22-150100.3.120.1, zypper-1.14.66-150100.3.90.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-RU-2023:4535-1: An update that has five fixes can now be installed. Category: recommended (moderate) Bug References: 1041742, 1203760, 1212422, 1215979, 1216091 Sources used: SUSE Enterprise Storage 7.1 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise Micro 5.1 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise Micro 5.2 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise Micro for Rancher 5.2 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise Server 15 SP2 (src): libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise Server 15 SP3 (src): libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise High Performance Computing ESPOS 15 SP3 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Manager Proxy 4.2 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Manager Retail Branch Server 4.2 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 SUSE Manager Server 4.2 (src): zypper-1.14.66-150200.65.1, libzypp-17.31.22-150200.78.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-RU-2023:4534-1: An update that has five fixes can now be installed. Category: recommended (moderate) Bug References: 1041742, 1203760, 1212422, 1215979, 1216091 Sources used: openSUSE Leap 15.4 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 openSUSE Leap Micro 5.3 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 openSUSE Leap Micro 5.4 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 openSUSE Leap 15.5 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise High Performance Computing 15 SP4 (src): libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Server 15 SP4 (src): libzypp-17.31.22-150400.3.43.1 SUSE Manager Server 4.3 (src): libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Server for SAP Applications 15 SP4 (src): libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Desktop 15 SP4 (src): libzypp-17.31.22-150400.3.43.1 SUSE Manager Retail Branch Server 4.3 (src): libzypp-17.31.22-150400.3.43.1 SUSE Manager Proxy 4.3 (src): libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise High Performance Computing 15 SP5 (src): libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Server 15 SP5 (src): libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Server for SAP Applications 15 SP5 (src): libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Desktop 15 SP5 (src): libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Micro for Rancher 5.3 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Micro 5.3 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Micro for Rancher 5.4 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Micro 5.4 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 SUSE Linux Enterprise Micro 5.5 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 Basesystem Module 15-SP4 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 Basesystem Module 15-SP5 (src): zypper-1.14.66-150400.3.35.1, libzypp-17.31.22-150400.3.43.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.