Bug 535432

see old bug revisited https://bugzilla.novell.com/show_bug.cgi?id=379480

I think the expected result should be "zypper will refuse to update rpm because it involves removing satsolver-tools and libzypp"

rpm-4.7.1 no longer provides librpmdb-4.4.so

*** Bug 535505 has been marked as a duplicate of this bug. ***

This is an excerpt from rpm.org api changes between 4.4.2 and 4.6.0 :-
librpmdb has been merged with librpm. The split was largely artificial and caused more entirely unnecessary problems than it solved.

*** Bug 379480 has been marked as a duplicate of this bug. ***

I'm still learning but if all the functions are available in librpm couldn't a link simply be created to librpmdb?

I'm still learning but if all the functions are available in librpm couldn't a link simply be created for librpmdb?

The problem is that factory is inconsistent. It contains a new rpm package, but dependent packages like e.g. zypper/libzypp are still old (linked against rpm-4.4).


The second problem, and IMO the only thing we could/should? fix, is that 
'zypper in' still uses force resolve. 

Without this, the suggested deletion of zypper/libzyp/etc. would have been reported as dependency conflict, telling that there is no provider for librpmdb-4.4. With this information one might recognize that factory is not consistent. At least one has to explicitly confirm the deletion.

Currently (with --force) zypper behaves as if everything went well.


One may use --force per default when removing packages, but I don't know why it should be needed when installing. It just disguises potential problems.

If zypper in didn't use force-resolution as default it would behave like yast sw_single and present the user, in some cases, with a large number of choices and lose some of it's ease of use. Shouldn't it simply refuse to remove certain files.
I have enabled /etc/zypp/systemCheck in zypp.conf and added requires:libzypp and requires:satsolver-tools to it and I get an error message when I try to install rpm using zypper in. This should be a system default IMHO and solve the possibility of breaking the installation system.
Doesn't solve the other packages dependencies on librpmdb though.

I now have factory rpm 4.7.1 installed along with updated libzypp and satsolver-tools. The only package I had to rebuild was kdeutils3 and had to allow the removal of  rpmlint-Factory and rpmlint-mini only. They will most probably catch up soon.

(In reply to comment #10)
> I have enabled /etc/zypp/systemCheck in zypp.conf and added requires:libzypp
> and requires:satsolver-tools to it and I get an error message when I try to
> install rpm using zypper in. This should be a system default IMHO and solve the
> possibility of breaking the installation system.

Yes, it would be nice, but it's not that simple, see http://lists.opensuse.org/zypp-devel/2009-08/msg00012.html . For now we stick with leaving this to the user.


(In reply to comment #9)
> The second problem, and IMO the only thing we could/should? fix, is that 
> 'zypper in' still uses force resolve. 

For a good reason - most of the time you get good results, and that's without being bothered by dependency resolution dialogs; e.g. in case the install/upgrade results in removing some other package, which needs yet another packages to be removed.

> Without this, the suggested deletion of zypper/libzyp/etc. would have been
> reported as dependency conflict, telling that there is no provider for
> librpmdb-4.4. With this information one might recognize that factory is not
> consistent. At least one has to explicitly confirm the deletion.
> 
> Currently (with --force) zypper behaves as if everything went well.

Maybe is something that should be fixed. Currently zypper only adds 'p' (for 'show problems') to the 'Continue?' prompt in case 'in' deletes or 'rm' installs. Maybe this could be made more obvious. It could drop a line like "There were some dependency problems resolved automatically. Choose 'p' to try again a choose the solutions yourself.". What do you think?

BTW, 'p' restarts the solver again, but with --no-force-resolution.

> One may use --force per default when removing packages, but I don't know why it
> should be needed when installing. It just disguises potential problems.

See above. In short, also 'install' often removes packages.

Like I said in comment 10 if I have enabled /etc/zypp/systemCheck in zypp.conf and added requires:libzypp and requires:satsolver-tools to it and I get an error message when I try to install rpm using zypper in this will prevent me from breaking my installation system. If this was a system default then there wouldn't be a problem. Obviously an upgrade like rpm 4.7 wouldn't occur in a release version, only in factory.

(In reply to comment #12)
> 'show problems') to the 'Continue?' prompt in case 'in' deletes or 'rm'
> installs. Maybe this could be made more obvious. It could drop a line like
> "There were some dependency problems resolved automatically. Choose 'p' to try
> again a choose the solutions yourself.". What do you think?

Maybe: Add an option to your zypper.conf, so I can disable auto-using --force.

As long as --force is on, you won't convince me that --force is necessary or helpful.

(In reply to comment #14)
> 
> Maybe: Add an option to your zypper.conf, so I can disable auto-using --force.
> 
> As long as --force is on, you won't convince me that --force is necessary or
> helpful.
"-f, --force 
 Install even if the item is already installed (reinstall)" taken from man zypper.
isn't a default, --force-resolution is a default for zypper install and causes packages to be marked for deletion and normally makes life easier. If certain packages which it would be illogical to remove such as rpm, libzypp and satsolver-tools that make the base installation system were in /etc/zypp/systemCheck and systemCheck was enabled in zypp.conf by default then problems like this would never occur and the installation system would never remove itself at least without warning the user.
see https://bugzilla.novell.com/show_bug.cgi?id=379480#c8

Hi guys, so what do we do with this? (and let's forget about the forceResoltuion, we discuss that in bug 548017)

Read through the report again, so here's the summary:

* the original problem (new rpm, old zypp in factory) => FIXED
* the suggestion to add zypp to /etc/zypp/systemCheck => WONTFIX
  (as explained in c#10)
* zypper.conf now has solver.forceResoltuionCommands => FIXED in 1.2.12
  (you can configure which commands should use the flag)

I guess we can close this issue now.