Bug 1219345

(In reply to Martin Wilck from comment #0)
> the package has been rebuilt and some checksums don't match, while the
> version/release is the same as before.

That's the issue. It's no longer the same package with the same content but sill uses the same version-release. OBS should not do this. If the content changed the build count should be increased.

ZYPP_SINGLE_RPMTRANS most probably gives you the same file conflicts as a re-install with plain rpm does. That's the purpose of ZYPP_SINGLE_RPMTRANS.

IMO it's not a bug in zypp, but in OBS (unless rpm on the commandline would not complain)

But zypper realizes that it's a *re*installation, i.e. the old package is removed and the new one installed:

> The following package is going to be reinstalled:
>   kernel-default-6.7.1-2.1

No, a re-install is not 'remove and install'. 
It's an `update` to the same version (rpm -U --replacepkgs).

(In reply to Michael Andres from comment #3)
> No, a re-install is not 'remove and install'. 
> It's an `update` to the same version (rpm -U --replacepkgs).

Well, yes, I'm already a step ahead there. Main point is that after the update, the package is replaced, i.e. only one of either the old or new packages will be installed. So file conflicts can't happen. Otherwise no package update could ever be installed.

I guess there is some conflict with the multiversion functionality.

(In reply to Michael Andres from comment #3)
> No, a re-install is not 'remove and install'. 
> It's an `update` to the same version (rpm -U --replacepkgs).

Not confirmed. I just ran 

rpm -U --replacepkgs /var/cache/zypp/packages/download.opensuse.org-oss/x86_64/kernel-default-6.7.1-2.1.x86_64.rpm

and I got no conflicts.

(In reply to Fabian Vogt from comment #4)
> I guess there is some conflict with the multiversion functionality.

You're probably right. With multiversion on it's `rpm -i --replacepkg`, so rpm does not obsoelete the old version(s).

It would all be no issue if OBS would increment the build count.

(In reply to Martin Wilck from comment #5)
> Not confirmed. I just ran 
> 
> rpm -U --replacepkgs

Maybe my fault, if multiversion is on: `rpm -i --replacepkg`

Unfortunately the rpm -U destroyed my test bed ;-)
I'll have to roll back to test this.

It makes sense that this is caused by multiversion + the messed-up versioning of the kernel package. The missing piece (for me) is why it only happens with ZYPP_SINGLE_RPMTRANS=1.

(In reply to Martin Wilck from comment #8)
> happens with ZYPP_SINGLE_RPMTRANS=1.

Because with ZYPP_SINGLE_RPMTRANS librpm drives the whole transaction.

In the traditional installer we use a single 'rpm --shut-up-and-do-what-we-tell-;)' for every package. The file conflict check is done by libsolv because rpm itself never sees the whole transaction. Might be libsolv is more relaxed in this case. (@mls might know)

(In reply to Michael Andres from comment #7)

> Maybe my fault, if multiversion is on: `rpm -i --replacepkg`

Indeed, this fails with the same messages as "zypper dup" with ZYPP_SINGLE_RPMTRANS=1.

So my takeway here is that it's really unfortunate coincidence of multiversion, the logic of librpm, and the versioning of this specific kernel package in factory.

This constellation is unlikely to happen again any time soon. Thus I suppose it isn't worth putting in additional resources. Not many people seem to have been affected so far, and as soon as TW releases a new kernel, the issue will be gone.

We should keep an eye on the behavior of OBS though; I believe that version/release numbers should always increase in a distribution, and that our QA/release tools should catch this situation before it occurs.

As far as I'm concerned, the bug can be closed.

(In reply to Martin Wilck from comment #11)
> version/release numbers should always increase in a distribution, and that
> our QA/release tools should catch this situation before it occurs.

 +1

>As far as I'm concerned, the bug can be closed.

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