Comment # 16 on bug 1206042 from
(In reply to Martin Wilck from comment #14)
> update. Having "conflicts: kernel < 5.14.21-150400.24" would mean a conflict
> not only with the SLE15-SP4 GA kernel, but with *every* SLE15-SP3 and older

If there is a significant provides indicating that the run_if_exists is
included, a conflict against this would hit only the kernel versions that
provide it.


>  If the "silent remove" deterministically happens early on 
> (before upgrading suse-module-tools)

Well, this very much depends on package dependencies. The package is not
removed as long as installed packages require it (e.g. for their %postun). You
can just tell how long the solver tries to keep this package. Cyclic
dependencies which need to be broken up may cause an earlier deletion. A later
deletion is always possible.

A somewhat deterministic point of deletion is just given for obsoletes. An
obsoleted package is treated as an old (not multiversion) version. When
installing the new package rpm itself removes the old (and obsoleted) ones.

-----
What you could try if it must happen `before upgrading suse-module-tools`:

- let the new suse-module-tools 
  pre-require `( suse-module-tools-cleanup if kernel < [whatever....] ).

- create suse-module-tools-cleanup as a task package which just 
  obsoletes the 'kernel < [whatever....' caused it's installation.

As a pre-requires the solver will always try to keep it before
suse-module-tools. Unless you have really ugly dependency cycles, this should
do.

Question is how to get rid of suse-module-tools-cleanup again. You have to try
out or ask Michael Schr���der (mls) whether this works within the same
transaction:
a) suse-module-tools could immediately obsolete suse-module-tools-cleanup
again.
b) suse-module-tools-cleanup could provide `libsolv-self-destruct-pkg()`. By
this the package requests it's own removal immediately after having been
installed. In case this works, ask mls whether libsolv-self-destruct-pkg() is
mature enough to be use in production code.


You are receiving this mail because: