Am Mon, 14 Dec 2020 11:37:15 +0100 schrieb Olaf Hering :

Am Mon, 14 Dec 2020 11:19:19 +0100 schrieb Dan Čermák :

...

%transfiletrigger I had no idea such thing exists.

How are these things actually ordered, would this even be able to solve the issue? As shown earlier, the "*.rpmsave" handling needs to be done with %pre+%posttrans. This means these triggers must run after %posttrans, because otherwise the 'try-restart' will fail as it does now. Olaf

On Mon, Dec 14, 2020 at 5:38 AM Dominique Leuenberger / DimStar wrote:

On Mon, 2020-12-14 at 11:19 +0100, Dan Čermák wrote:

...

Olaf Hering writes:

...

Did anyone already explore the potential pitfalls of moving "restart on update" from %postun to %posttrans?

There is one catch: if there are %posttrans scriptlets in a package, then libzypp will invoke rpm with `--noposttrans` [1] which also prevents %transfiletrigger scriptlets from firing. Zypper then invokes the collected posttrans scriptlets after the transaction, but it never invokes the transaction file triggers.

Which is why we do not accept transfiletriggers in Factory (except vagrant - where somehow it was missed)

as zypp installs every RPM as an own transaction, in any case, transfiletrigger reacts exactly the same as filetrigger in our cases. The existing triggers can simply be converted at no lose of functionality (well, some loss - if somebody were to install using pure rpm, they might have a benefit; Possibly also if using DNF, not sure exactly how that does the transaction handling in openSUSE)

DNF uses librpm to run the transaction the same way RPM would. That is, all the packages are collected and installed in a single transaction, so transfiletrigger works correctly. File triggers (especially transfiletriggers) are used extensively in Fedora, Mageia, and OpenMandriva (where DNF is used), so I know that it works pretty much perfectly. Switching to DNF means the issue we have around transaction scriptlets goes away. -- 真実はいつも一つ！/ Always, there's only one truth!

On Monday 2020-12-14 14:09, Dominique Leuenberger / DimStar wrote:

On Mon, 2020-12-14 at 07:58 -0500, Neal Gompa wrote:

...

DNF uses librpm to run the transaction the same way RPM would. That is, all the packages are collected and installed in a single transaction, so transfiletrigger works correctly. File triggers (especially transfiletriggers) are used extensively in Fedora, Mageia, and OpenMandriva (where DNF is used), so I know that it works pretty much perfectly.

Switching to DNF means the issue we have around transaction scriptlets goes away.

And others appear :)

Yeah, I'll just point back to https://lists.opensuse.org/opensuse-factory/2020-07/msg00066.html

On Mon, Dec 14, 2020 at 8:18 AM Neal Gompa wrote:

On Mon, Dec 14, 2020 at 8:09 AM Dominique Leuenberger / DimStar wrote:

...

On Mon, 2020-12-14 at 07:58 -0500, Neal Gompa wrote:

...

DNF uses librpm to run the transaction the same way RPM would. That is, all the packages are collected and installed in a single transaction, so transfiletrigger works correctly. File triggers (especially transfiletriggers) are used extensively in Fedora, Mageia, and OpenMandriva (where DNF is used), so I know that it works pretty much perfectly.

Switching to DNF means the issue we have around transaction scriptlets goes away.

And others appear :)

DNF is interesting - and I started playing with it a bit too. What boggles me most so far is that we cannot just mix-and-match zypper and dnf. As a user, I have to either opt to use one (and not use the other) or maintain both in good stading order. What I mean, especially, is that the repo files/definitions are not being shared.

If I was to switch to dnf, then all the yast tools might get the wrong info, as they are using the libzypp/zypper backend - whereas aas user I interact with dnf and use different repositories. yaiks.

compare to zypper dup, dnf upgrade (somehow I assumed this would be the right thing for TW) does not offer downgrades.

And the third thing I found while just running it in first trials that it wanted to install 'some -lang' packages (very few). on zypp, I have *-lang locked, so I am clear not to have any installed. as dnf does not use my locks (I guess) I was quite surprised that it only wanted to install like 3 -lang packages - of course honoring my zypp lock would be even better)

This mail is not meant to dimish the work done in DNF - it seems to do what it advertises, something a bit better than zypper, somethings different, something possibly worse.

Advertising it as 'the solution to all problems' is a bit premature though.

I had intentionally not configured DNF to read /etc/zypp/repos.d by default because of how Zypper rewrites repo files every time it processed them into invalid repo files (with type=NONE, among others). That caused DNF to automatically expire its cache and stop working.

I would *love* to unify configuration between the two, but fixing YaST and everything else zypp-based to do the right thing is a bit of a pain. I'd like to get everything using rpm-repos-openSUSE instead of installing repos itself through the product.xml, and somehow get Zypper to stop rewriting repo files every time it read them...

Eck, I hit the send button too soon... The analogue to zypper dist-upgrade is "dnf distro-sync", and the "dup" short command is an alias to "dsync" (the shorthand version of distro-sync subcommand). DNF does not normally autoremove packages it doesn't know about, though you can ask it to autoremove unused leaves at any time with "dnf autoremove". For locks, there's a DNF has "excludes" for that, and there's a versionlock plugin that lets you manage them similarly to zypper locks[1]. [1]: https://www.mankier.com/8/dnf-versionlock -- 真実はいつも一つ！/ Always, there's only one truth!

Dominique Leuenberger / DimStar composed on 2020-12-14 14:09 (UTC+0100):

On Mon, 2020-12-14 at 07:58 -0500, Neal Gompa wrote:

...

Switching to DNF means the issue we have around transaction scriptlets goes away.

And others appear :)

DNF inherited most of the disadvantages of YUM. Its conglomeration of long-winded name plugins and accompanying suite of man pages is horrible. Its locking system is particularly frustrating compared to Zypper. Zypper's creators obviously were familiar with them, and avoided repeating them. I rarely use YaST* for software management. Zypper makes command line package management, and openSUSE, a pleasure. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

Olaf Hering wrote:

Am Mon, 14 Dec 2020 13:10:15 +0100 schrieb Ludwig Nussel :

...

I'd love to see us phasing out those scriptlets in favor of file triggers.

Is this a realistic goal? The bug referenced in that other email left this question unanswered AFAICS.

Normal, per package file triggers work fine. So at least the current behavior of the scriptlets could be reimplemented as triggers. To be able to execute something at the end of the transaction as you suggested, a bit more creativity would be needed. Eg a combination of file triggers collecting information about changes and a regular posttrans script. Or maybe threaten to use the old and crappy /var/adm/update-scripts again. Haven't researched the options myself yet. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

Am Wed, 16 Dec 2020 10:08:43 +0100 schrieb Dan Čermák :

transaction file triggers

This other idea is about moving the "restart" around, which is unrelated to what needs to be fixed for SUSE: we need to remove files below /etc from packages, which requires to preserve modified files that where marked as %config. A brief search gave no hints about the ordering of these "triggers". In other words: will the 'mv' happen before the 'try-restart'? Olaf

Am Wed, 16 Dec 2020 10:50:47 +0100 schrieb Dan Čermák :

first %transfiletriggerun are run, then %posttrans, then %transfiletriggerpostun and at last %transfiletriggerin.

If that is true, %posttrans could do the 'mv', and '%transfiletriggerin' does the 'restart'? If we touch it anyway we have to make sure the old package does nothing in all its '%*uninstall' scripts during package update. Olaf

Olaf Hering writes:

...

Am Wed, 16 Dec 2020 10:08:43 +0100 schrieb Dan Čermák :

...

transaction file triggers This other idea is about moving the "restart" around, which is unrelated to what needs to be fixed for SUSE: we need to remove files below /etc from packages, which requires to preserve modified files that where marked as %config. A brief search gave no hints about the ordering of these "triggers".

If I understand https://github.com/rpm-software-management/rpm/blob/5ce2b5e3121aa07eb1ccf2bc... correctly, then first %transfiletriggerun are run, then %posttrans, then %transfiletriggerpostun and at last %transfiletriggerin.

I am not sure how exactly the %posttrans scriptlets are ordered, but my guess from https://github.com/rpm-software-management/rpm/blob/5ce2b5e3121aa07eb1ccf2bc... is that they are run in the same order that the packages are installed/upgraded.

This all of course only applies if you use rpm/librpm to run these scriptlets, which afaik is not done by zypper. Maybe Michael and/or Benjamin can shed some light here? Currently the transfiletrigger are not executed by zypper because we are installing each rpm package separately collecting the posttrans scripts by using a feature that disables them and instead prints which scripts would have been run. RPM has not yet a feature to detect the transfiletriggers that would've been executed, sadly the previously mentioned feature disables the

Am 16.12.20 um 10:50 schrieb Dan Čermák: them completely.

Cheers,

Dan

-- Benjamin Zeller Systems Programmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuremberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer