Bug 210552

Same for my workstation which is successive updated from 9.3 or so...

Please provide YaST2 logs as per http://en.openSUSE.org/Bugs/YaST and be more specific on what's wrong.

Created attachment 101305 [details]
yast2 log

The problem is that in the yast "Software Managment" module (sw_single) both Patterns and the Selections they replace are selectable in the main view combo box.  Shouldn't Selections be removed by now?

What not do the real fix and remove local selection definition cruft during update?

Removing selections is not the right approach. There may be selections comming from add-on products.

The right appropach is to obsolete/provide the 10.1 selections by respective patterns.

How can I remove selections coming from third party add-on products?

Could you tell me what should be done exactly?  Just give me an example and I'll do the rest ;-)

And do you want to remove such selection? IMO we should remove only our selection and keep the 3rd party selections installed, or?

Duncan, can Obsoletes/Provides for selection be specified in the SUSEtags pattern metadata?

The tags are Obs and Prv

TEll me *exactly* what I should do.

E.g. add to pattern basesystem the following:
+Obs:
list of all selections from 10.1 (with version numberS)

example for this
-Obs:
+Prv:
list of all
exampe for this.
-Prv:

Just consider I'm really dumb ;-)

So, what should I add there as obsoletes/provides:

Voip-10.1-67

Voip <= 10.1
Voip

Or what else?

Klaus and myself discussed this and we think that during an update from pre-10.2 to 10.2 we should do:
* Delete all installed selections
* Delete all installed patches

We do not handle selections anymore, let's not try to read old ones.

Jiri, can you get this done until monday as part of yast2-update so that we can test it next week?

Note this is for all future products, we should *always* do:

* Deletion of all installed patches
* Deletion of all installed selections

Patterns do not need to be touched, they will be updated.

This might need further discussions for SPs.

I think this can be fixed during tomorrow (uninstalling all patches/selections can be done before packages get updated). Lukas, please, have a look.

Note that if there is an add-on product, it also deletes its patches. However, the updated packages keep installed, so it doesn't break the add-on product being up-to-date.

Solution is ready, however it needs to be properly tested (At least with updated 10.1 maybe also with some other version).

Bugfix can be expected by Friday afternoon.

Hmm, testing on 10.1:

Removing `patch-es removes [atom]s and [patch]es - OK
However removing `selection-s removes also [package]s - Wrong :(

Needs to be consulted with lslezak.

I guess for selections and patches, we need a brute-force approach of directly accessing the zypp database on the to-be-upgraded partition, prior to starting libzypp on that partition.

Sounds somewhat hackish ;-)

Does zypp support something like the   rpm --justdb  (and/or --nodeps for the selections)? If yes, it should be the preferred way ;-)

Created attachment 104603 [details]
Testcase -- YCP Script

Run the installation with Linuxrc parameter: 
start_shell=1
Then run:
`/usr/lib/YaST2/bin/y2base /path/to/update_remove.ycp qt`
See y2log...

If you try to run this on a running and updated 10.1 machine, you will have to change two things:
1.) string target = "/mnt"; -> string target = "/";
2.) Pkg::TargetInitialize (target); -> Pkg::TargetInit (target, false);

Created attachment 104604 [details]
Y2log from running this script in the inst-sys

~(There is a fully-updated 10.1 mounted in /mnt)~

The problem with uninstalling packages could be solved using Pkg::PkgNeutral(), but I think that the problem should be solved in a better way.

I just have tested a possibility of using zypp::storage::PersistentStorage directly. Using the storage it's possible to operate on the libzypp DB level
(something like "rpm --justdb" as is mentioned in comment #17) and remove resolvables without touching the filesystem (except the DB).

I propose a new pkg-binding Pkg::TargetStoreRemove(symbol kind), which will remove all resolvables of the kind (e.g. `patch, `selection). If we do not want global remove I can add "name" parameter.

To remove the selection from the updated system we would use Pkg::TargetStoreRemove(`selection). But I'm not sure about patches, if they add new files to the system they should be probably cleanly uninstalled (using Pkg::ResolvableRemove).

Someone from zypp team should comment my solution...

Created attachment 104619 [details]
excerpt of Pkg::TargetStoreRemove()

Here is code of the proposed binding.

comment #17,#20: Agreed, something like '--justdb' is probably the right approach.

Michael, please have a look and comment.

OK, we are already implementing this solution:

Patches will be removed one-by-one with Pkg::ResolvableRemove() call because there might be some additional files (added by patches) that needs to be removed. This is the right way to remove an installed patch.

Selections will be removed by Pkg::TargetStoreRemove() call which only removes the information about selection but not the selection itself.

This functionality will be called just before the installation of packages (in inst_rpmcopy script) is started (actually after the target is initialized). It will be called in both first and second stages because ... hmm it is safer :) and JSrain tells that some files/patches could stay there...

It will be done and pre-tested today.

Hmm, calling Pkg::ResolvableRemove() just didn't work because it tried to also call some scripts, restart zmd, etc.

Used fix:
Calling Pkg::TargetStoreRemove() for both patches and selections (works) because this is the only way...

This will be in yast2-packager-2.14.6 and yast2-package-bindings-2.14.0

Just testing... and it seems to work well. I'll reopen the bug by myself if it doesn't work. For now -> FIXED.