Mailinglist Archive: opensuse-features (40 mails)

< Previous Next >
[openFATE 313088] allow patches that uninstall packages
Feature changed by: Jiri Srain (jsrain)
Feature #313088, revision 19
Title: allow patches that uninstall packages

openSUSE Distribution: Unconfirmed
Requester: Important

Requested by: Ludwig Nussel (lnussel)
Partner organization:

suppose security flaws are discovered in some leaf package that we
cannot fix for some reason. We need a way to tell users of that package
that they better uninstall the affected package. Previously we would
have "solved" this by releasing a new version of the package without
files. This is a rather ugly hack though. What we need is a special
patch that when selected uninstalls the listed packages without causing
e.g. packagekit to choke.

#1: Michael Schröder (mlschroe) (2011-12-19 15:52:44)
As often, the libzypp/solver part is easy. Please propose how you want
to encode such an uninstall request into updateinfo.xml. Also please
ask the Fedora guys about their opinion, as we share the

#2: Ludwig Nussel (lnussel) (2011-12-19 16:03:37) (reply to #1)
please go ahead, you're the expert

#3: Michael Schröder (mlschroe) (2011-12-19 16:07:23) (reply to #2)
But I'm not the Architect(TM)

#4: Karl Cheng (qantas94heavy) (2016-11-18 04:04:22)
I wonder if you think this is still right today, Ludwig... ;)

#5: Ludwig Nussel (lnussel) (2016-12-05 15:02:54) (reply to #4)
Yes I think so. It's also interesting for e.g. openSUSE:Backports

#6: Sławomir Lach (lachu) (2016-12-06 17:12:37)
It is good idea to also disallow to install package with security

#8: Kai Dupke (kdupke) (2017-02-17 11:54:04) (reply to #6)
Users might see this as too much managing them. And there might be
reasons you want to have exactly this specific version, even it has a
security flaw. Of course, having someone to acknowledge on this could
be worth.

#9: Jiri Srain (jsrain) (2017-04-10 08:04:07Z)
I wonder if we need any handling in updateinfo at all. Can the patch
itself just conflict with package we want to remove?
Thorsten, you may want to have a look as an architect...

#10: Michael Andres (mlandres) (2017-04-19 08:40:22) (reply to #9)
Inside libsolv/libzypp a patch is an ordinary object just like a
package. A patch is created from an entry in updateinfo.xml by
translating the package list into a set of conflict dependencies. This
way the patch will conflict with installed versions less than the ones
mentioned in the updateinfo.xml.
A patch with actual conflicts, is called broken or needed. If such a
patch is selected, dependency resolution can resolve such conflict by
either updating the package or by removing it.
The common resolution to update the package is just because the update-
repo also provides the new rpm packages. If we'd mention a package in
the updateinfo.xml, but do not ship a new rpm package as well,
dependency resolution will (interactively) suggest to remove the the
package. For the sake of being more explicit or if we want to non-
interactively remove packages, we need to indicate that 'a package is
intentionally not shipped' (i.e. to be deleted) in the upadetinfo.xml.
Michael Schröder is probably more familiar with the upadetinfo.xml
format and he also 'owns' the parser; maybe he has some suggestion how
to encode this. Maybe just '<package>' entries without src/filename
attributes or an explicit '<delpkglist>'? Edit (#) Reply (#)

#13: Michael Calmer (mcalmer) (2017-04-20 07:24:36) (reply to #10)
If the format of updateinfo.xml change or new elements are added please
remember that we need to adapt SUSE Manager as well. Either to be able
to parse the new elements and to write out the new updateinfo with the
new elements.
Interactive apply would not be a good idea in case of SUSE Manager
remove installation of patches. So we should implement it in a way that
no explicit verification is required. Like Kai explained.

#11: Kai Dupke (kdupke) (2017-04-19 09:07:00Z) (reply to #10)
The base idea behind this request is the need to uninstall a package by
a patch. Which means, as soon as the patch is selected for
installation, the referred package shall be uninstalled without being
This can be because a package is insecure and as such shall be removed
(so the patch is named 'remove ABC', and the content is to remove the
package ABC - which later shows by the RPM list that this was actively
Of course, if the removal can't be done because other packages have
dependencies which are not fulfilled after removal of the referred
package, a conflict resolution should come up.

#12: Jiri Srain (jsrain) (2017-04-20 06:57:22Z) (reply to #10)
Thank you, Michael, this approach sounds reasonable. I don't really
like <package> entries without filename; you would need to specify a
version here, simply to make it up somehow, I personally prefer an
explicit tag.
Michael S., can you, please, drive this further? Do you need any
architect support (comment#3) or any help from other areas for this?
Adrian, how about the metadata generators?

+ #14: Jiri Srain (jsrain) (2017-04-26 08:41:48Z)
+ Johannes, Lars, please, proceed with the evaluation. I like the
+ proposal which Michael A. brought, we need to support both using such
+ metadata as well as creating them.

openSUSE Feature:

< Previous Next >
This Thread