Feature changed by: Michael Schröder (mlschroe) Feature #309619, revision 3 Title: Make zypp use a single RPM transaction (no --force) Requested by: Andrew Jorgensen (ajorgensen) Partner organization: openSUSE.org Description: Zypp currently does a force install of each RPM individually, this has the nasty side-effect of ignoring file conflicts and probably has a number of other nasty side-effects we don't know about.  It's just a bad practice to force installation.  Zypp should instead use a single RPM transaction to install all packages, without using --force. Business case (Partner benefit): openSUSE.org: Because it is so very wrong to force installation as a normal routine part of maintenance and we really need to stop this egregious practice. + Discussion: + #1: Michael Schröder (mlschroe) (2010-05-28 18:54:20) + (Uh oh, not again...) + This is not about --force. The checks you want have to be done *before* + the transaction starts. You're confusing the transaction check with the + actual execution of the transaction. It makes no sense at all to run a + single transaction step without '--force', as it's normal to have file + conflicts in the middle of the execution. + You probably want libzypp to check for file conflicts (which it + currently doesn't do). The satsolver library already supports this (for + example try the little package manager "solv" from the libsatsolver- + demo package), there's just a little part missing in libzypp. The good + thing is that when there is a file conflict we can retrofit it into the + package dependencies and rerun the solver. + If the transaction is executed with one single librpm call or with + multiple steps should not matter at all, it is only done for safety so + that the complete transaction is not hosed if one of the steps fails. -- openSUSE Feature: https://features.opensuse.org/309619

Feature changed by: Andrew Jorgensen (ajorgensen) Feature #309619, revision 5 Title: Make zypp use a single RPM transaction (no --force) Requested by: Andrew Jorgensen (ajorgensen) Partner organization: openSUSE.org Description: Zypp currently does a force install of each RPM individually, this has the nasty side-effect of ignoring file conflicts and probably has a number of other nasty side-effects we don't know about.  It's just a bad practice to force installation.  Zypp should instead use a single RPM transaction to install all packages, without using --force. Business case (Partner benefit): openSUSE.org: Because it is so very wrong to force installation as a normal routine part of maintenance and we really need to stop this egregious practice. Discussion: #1: Michael Schröder (mlschroe) (2010-05-28 18:54:20) (Uh oh, not again...) This is not about --force. The checks you want have to be done *before* the transaction starts. You're confusing the transaction check with the actual execution of the transaction. It makes no sense at all to run a single transaction step without '--force', as it's normal to have file conflicts in the middle of the execution. You probably want libzypp to check for file conflicts (which it currently doesn't do). The satsolver library already supports this (for example try the little package manager "solv" from the libsatsolver- demo package), there's just a little part missing in libzypp. The good thing is that when there is a file conflict we can retrofit it into the package dependencies and rerun the solver. If the transaction is executed with one single librpm call or with multiple steps should not matter at all, it is only done for safety so that the complete transaction is not hosed if one of the steps fails. #2: Andrew Jorgensen (ajorgensen) (2010-05-28 22:30:56) (reply to #1) If we use a single transaction without --force all of these checks *will* be done before the transaction starts.  I see that as desirable.  Your statement "it's normal to have file conflicts in the middle of the execution" confuses me.  Doesn't rpm handle that kind of thing gracefully when run as a single transaction?  I'm certain that other rpm package managers (yum) use a single transaction and never run into the problem I think you're hinting at. As a counter-example: Today I upgraded to a new version of a package (mono-data-sqlite) where a part of the package had been split out into separate package (mono-data-sqliteclient).  Zypper installed the new mono-data-sqliteclient before replacing the old mono-data-sqlite with the new one, this resulted in the files from the new mono-data- sqliteclient being deleted from my system.  RPM would not have made this mistake in a single transaction. Why do we want to reinvent the wheel by trying to make satsolver install things in the right order when RPM already does that?  The ideal solution would be to have satsolver figure out what to install and let RPM figure out how to install it. Can you explain in more detail why --force is desirable?  Maybe provide an example where it performs more correctly than a single transaction? + #3: Andrew Jorgensen (ajorgensen) (2010-05-28 23:03:44) (reply to #1) + Okay, I was a little mistaken about how those files when missing.  They + disappeared because zypp thought it was okay for mono-data-sqlite and + mono-data-sqliteclient to be installed at the same time (there are file + conflicts but no package conflict) so it replaced mono-data-sqlite and + did nothing at all with mono-data-sqliteclient.  The result is that the + conflicting files are now erased. + I admit that adding file conflict support to zypp would be a big step + in the right direction but I still can't see why --force is + desirable.  It's called --force because it forces rpm to ignore things + that it knows are wrong.  It's only useful to zypp because zypp will + sometimes do things wrong.  Removing --force and performing a single + transaction may reveal remaining bugs in satsolver, which we should + fix. + Another reason to use a single transaction is to have rollback + support.  If some part of the transaction fails RPM can undo the whole + transaction.  This has been possible since rpm 4.0.3. -- openSUSE Feature: https://features.opensuse.org/309619