Feature changed by: Ludwig Nussel (lnussel) Feature #313088, revision 4 Title: allow patches that uninstall packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. + #2: Ludwig Nussel (lnussel) (2011-12-19 16:03:37) (reply to #1) + please go ahead, you're the expert -- openSUSE Feature: https://features.opensuse.org/313088

Feature changed by: Karl Cheng (qantas94heavy) Feature #313088, revision 7 Title: allow patches that uninstall packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. #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... ;) -- openSUSE Feature: https://features.opensuse.org/313088

Feature changed by: Sławomir Lach (Lachu) Feature #313088, revision 9 Title: allow patches that uninstall packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. #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 + flaws? -- openSUSE Feature: https://features.opensuse.org/313088

Feature changed by: Stefan Behlert (sbehlert) Feature #313088, revision 12 Title: allow patches that uninstall packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. #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 flaws? - #8: Kai Dupke (kdupke) (2017-02-17 11:54:04Z) (reply to #6) + #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. -- openSUSE Feature: https://features.opensuse.org/313088

Feature changed by: Michael Andres (mlandres) Feature #313088, revision 14 Title: allow patches that uninstall packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. #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 flaws? #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 (#) -- openSUSE Feature: https://features.opensuse.org/313088

Feature changed by: Jiri Srain (jsrain) Feature #313088, revision 16 Title: allow patches that uninstall packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. #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 flaws? #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 (#) #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 interactive. 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 done). 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? -- openSUSE Feature: https://features.opensuse.org/313088

Feature changed by: Jiri Srain (jsrain) Feature #313088, revision 19 Title: allow patches that uninstall packages openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. #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 flaws? #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 interactive. 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 done). 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: https://features.opensuse.org/313088

Feature changed by: Ihno Krumreich (ihno) Feature #313088, revision 22 - Title: allow patches that uninstall packages + Title: Allow patches that uninstall packages openSUSE Distribution: Ready Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. #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 flaws? #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 interactive. 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 done). 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. #15: Lars Vogdt (lrupp) (2017-05-02 07:14:55Z) (reply to #14) I guess the implementation is not that complicated, but I hope that the outcome is really what we want. This should definitively become part of the Beta tests. Adrian, I'm setting this as validation here. Can you check if we can get this in as early as possible? -- openSUSE Feature: https://features.opensuse.org/313088

Feature changed by: Kai Dupke (kdupke) Feature #313088, revision 26 Title: Allow patches that uninstall packages openSUSE Distribution: Ready Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. #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 flaws? #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. #16: Klaus Kämpf (kwk) (2017-08-02 11:13:44) (reply to #8) How's sales and consulting reacting to this ? I as a customer would be less than happy to see a vendor de-installing a package from my system. + #18: Kai Dupke (kdupke) (2017-08-10 08:36:52Z) (reply to #16) + Having the capability does not mean to use the capability. + As an admin I still have to install the un-install package - no action + no loss. + I see 2 scenarios where stuff can be deleted automatically: + - distribution update - automated update + Of course, the later is a wanted behavior as automated update means + 'keep it up and secure', and if this includes deleting something then I + feel this is OK. + Of course, locking packages AFAIK has a higher priority as it does not + allow to handle the package. #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 interactive. 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 done). 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. #15: Lars Vogdt (lrupp) (2017-05-02 07:14:55Z) (reply to #14) I guess the implementation is not that complicated, but I hope that the outcome is really what we want. This should definitively become part of the Beta tests. Adrian, I'm setting this as validation here. Can you check if we can get this in as early as possible? #17: Klaus Kämpf (kwk) (2017-08-02 11:15:45) Implementing this in SUSE Manager is a *HUGE* effort since SUSE Manager parses and re-creates metadata. I do not think this feature (esp. given its age) is worth this. -- openSUSE Feature: https://features.opensuse.org/313088

Feature changed by: Michael Andres (mlandres) Feature #313088, revision 28 Title: Allow patches that uninstall packages openSUSE Distribution: Ready Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. #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 flaws? #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. #16: Klaus Kämpf (kwk) (2017-08-02 11:13:44) (reply to #8) How's sales and consulting reacting to this ? I as a customer would be less than happy to see a vendor de-installing a package from my system. #18: Kai Dupke (kdupke) (2017-08-10 08:36:52Z) (reply to #16) Having the capability does not mean to use the capability. As an admin I still have to install the un-install package - no action no loss. I see 2 scenarios where stuff can be deleted automatically: - distribution update - automated update Of course, the later is a wanted behavior as automated update means 'keep it up and secure', and if this includes deleting something then I feel this is OK. Of course, locking packages AFAIK has a higher priority as it does not allow to handle the package. #20: Ludwig Nussel (lnussel) (2017-08-10 08:51:23Z) (reply to #18) for distro upgrades we have weakremover already: $ rpm -q --provides openSUSE-release I guess maintenance could release the release package with updated weakremovers but that wouldn't be obvious to the customer and not sure if it would work. + #21: Michael Andres (mlandres) (2017-08-10 09:36:59) (reply to #20) + It depends, because the evauation of 'weakremover' is currently tied to + the product being updated by a plain 'dup' command. 'up or 'patch' + won't recognize it, and even for 'dup' the user can deiable it in + /etc/zypp/zypp.conf: + ## ## Whether dist upgrade should remove a products dropped packages. + ## ## A new product may suggest a list of old and no longer supported + ## packages (dropped packages). Performing a dist upgrade the solver ## + may try to delete them, even if they do not cause any dependency ## + problem. ## ## Turning this option off, the solver will not try to + remove those ## packages unless they actually do cause dependency + trouble. You may ## do the cleanup manually, or simply leave them + installed as long ## as you don't need the disk space. ## ## Valid + values: Boolean ## Default value: true ## # solver. + upgradeRemoveDroppedPackages = true #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 interactive. 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 done). 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. #15: Lars Vogdt (lrupp) (2017-05-02 07:14:55Z) (reply to #14) I guess the implementation is not that complicated, but I hope that the outcome is really what we want. This should definitively become part of the Beta tests. Adrian, I'm setting this as validation here. Can you check if we can get this in as early as possible? #17: Klaus Kämpf (kwk) (2017-08-02 11:15:45) Implementing this in SUSE Manager is a *HUGE* effort since SUSE Manager parses and re-creates metadata. I do not think this feature (esp. given its age) is worth this. -- openSUSE Feature: https://features.opensuse.org/313088

Feature changed by: Adrian Schröter (adrianSuSE) Feature #313088, revision 30 Title: Allow patches that uninstall packages openSUSE Distribution: Ready Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: 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. Discussion: #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 specification. #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 flaws? #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. #16: Klaus Kämpf (kwk) (2017-08-02 11:13:44) (reply to #8) How's sales and consulting reacting to this ? I as a customer would be less than happy to see a vendor de-installing a package from my system. #18: Kai Dupke (kdupke) (2017-08-10 08:36:52Z) (reply to #16) Having the capability does not mean to use the capability. As an admin I still have to install the un-install package - no action no loss. I see 2 scenarios where stuff can be deleted automatically: - distribution update - automated update Of course, the later is a wanted behavior as automated update means 'keep it up and secure', and if this includes deleting something then I feel this is OK. Of course, locking packages AFAIK has a higher priority as it does not allow to handle the package. #20: Ludwig Nussel (lnussel) (2017-08-10 08:51:23Z) (reply to #18) for distro upgrades we have weakremover already: $ rpm -q --provides openSUSE-release I guess maintenance could release the release package with updated weakremovers but that wouldn't be obvious to the customer and not sure if it would work. #21: Michael Andres (mlandres) (2017-08-10 09:36:59) (reply to #20) It depends, because the evauation of 'weakremover' is currently tied to the product being updated by a plain 'dup' command. 'up or 'patch' won't recognize it, and even for 'dup' the user can deiable it in /etc/zypp/zypp.conf: ## ## Whether dist upgrade should remove a products dropped packages. ## ## A new product may suggest a list of old and no longer supported ## packages (dropped packages). Performing a dist upgrade the solver ## may try to delete them, even if they do not cause any dependency ## problem. ## ## Turning this option off, the solver will not try to remove those ## packages unless they actually do cause dependency trouble. You may ## do the cleanup manually, or simply leave them installed as long ## as you don't need the disk space. ## ## Valid values: Boolean ## Default value: true ## # solver. upgradeRemoveDroppedPackages = true #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 interactive. 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 done). 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. #15: Lars Vogdt (lrupp) (2017-05-02 07:14:55Z) (reply to #14) I guess the implementation is not that complicated, but I hope that the outcome is really what we want. This should definitively become part of the Beta tests. Adrian, I'm setting this as validation here. Can you check if we can get this in as early as possible? #17: Klaus Kämpf (kwk) (2017-08-02 11:15:45) Implementing this in SUSE Manager is a *HUGE* effort since SUSE Manager parses and re-creates metadata. I do not think this feature (esp. given its age) is worth this. #22: Adrian Schröter (adriansuse) (2017-08-10 09:49:40Z) My simple proposal here would be to have an almost empty replacement package. That way it is also still visible that the package was installed and could be reinstalled again. Also all of that is working with standard mechanics, I guess. Just some rules how to create such a package might help. eg: a package called XYZ version 1.0 is affected. We want to drop it, so we build an empty package which is called XYZ-OBSOLETED. It provides and obsoletes XYZ. And it provides a file (zypper notification) which exmplains the issue. We can even restore that later by providing a XYZ-2.0 package which obsoletes XYZ-OBSOLETED < 2.0 then ... + #23: Adrian Schröter (adriansuse) (2017-08-10 10:11:33Z) + ignore my comment above, won't work via patch mechnic on zypp side. + However, are we sure we can't use Conflict here? It would mean that the + user will be asked by default, but is this a bad thing? Kay? + Otherwise, we could pre-install a package called eg. "distribution- + emergency-update" which is Conflicting with package XYZ. + That way the user can also opt-out from our standard behaviour by de- + installing the package. + Also the problem will appear during appliance builds. Something what + wouldn't be supported with additional meta data otherwise. -- openSUSE Feature: https://features.opensuse.org/313088