#1946 Updates process is broken
Closed: Invalid 5 years ago Opened 5 years ago by jwrdegoede.

Hi,

So today I found out that I caused a serious problem for Fedora 27 users, I did an innocent looking soundtouch security update, but I did not realize that F27 was at an older version and this implied a soname build.

In the past we would get a mail about updates which broken dependencies, but apparently this no longer happens.

IMHO problems with updates which can be detected automatically and with 100% reliability like these should block the update from going to stable, or at a minimum require me to click to a scary looking warning dialog in the updates web UI, that I'm pushing something which is known to be broken.

It seems that ATM there is no sort of dependency check running for updates at all, which is really bad IMHO. I double checked, it is not there in the "Automated Tests" tab in bodhi, nor did I get any mails from notifications@fedoraproject.org about a dep check failing either.

Note I'm not trying to shift blame here, the soundtouch problem is entirely my fault. But as this shows, mistakes happen and this one really should have been caught by our tooling/processes.

Regards,

Hans


@dperpeet is this something CI can help with?

well, as far as I can remember, there has never ever been a broken deps report for stable releases, unless it was manually run by someone. There is a rpmdep check in the taskotron checks, as well as a abi change test.

I assume we are talking about https://bodhi.fedoraproject.org/updates/FEDORA-2018-4197fff086 ?

I am very curious why the tests didn't catch this...

There is a abi change test: https://taskotron.fedoraproject.org/artifacts/all/043dcefe-8086-11e8-85cc-525400fc9f92/tests.yml/soundtouch-2.0.0-3.fc27.log

ABI changes between build soundtouch-2.0.0-3.fc27 and its latest stable build
================================================================================

This file contains possible ABI changes which have occurred due to this package update against latest stable build available in koji for the given Fedora release.

If you want to filter out these kind of ABI changes in the future, you can add a proper .abignore file to this package. To know more about how to write one, please look at the wiki page https://fedoraproject.org/wiki/Taskotron/Tasks/dist.abicheck#filtering .

On x86_64 architecture
*************************

* No ABI change between:
soundtouch-1.9.2-6.fc27.x86_64.rpm
soundtouch-2.0.0-3.fc27.x86_64.rpm
ABI comparison took 0.34 second(s).

* No ABI change between:
soundtouch-devel-1.9.2-6.fc27.x86_64.rpm
soundtouch-devel-2.0.0-3.fc27.x86_64.rpm
ABI comparison took 0.30 second(s).

* No ABI change between:
soundtouch-debugsource-1.9.2-6.fc27.x86_64.rpm
soundtouch-debugsource-2.0.0-3.fc27.x86_64.rpm
ABI comparison took 0.36 second(s).

and a dependency check: https://taskotron.fedoraproject.org/artifacts/all/e2e888e0-87db-11e8-9be3-525400fc9f92/tests.yml/itemlogs/soundtouch-2.0.0-3.fc27.x86_64.log

results:
- arch: x86_64
  checkname: dist.rpmdeplint
  item: soundtouch-2.0.0-3.fc27
  outcome: PASSED
  scenario: x86_64
  type: koji_build

So, something is wacky here. @kparal and/or @adamw any ideas why these tests passed here?

I fired up my F27 VM. This is the dependency error:

 Problem: package gstreamer1-plugins-bad-free-1.12.4-1.fc27.x86_64 requires libSoundTouch.so.1()(64bit), but none of the providers can be installed
  - cannot install both soundtouch-2.0.0-3.fc27.x86_64 and soundtouch-1.9.2-6.fc27.x86_64
  - cannot install both soundtouch-1.9.2-6.fc27.x86_64 and soundtouch-2.0.0-3.fc27.x86_64
  - cannot install the best update candidate for package soundtouch-1.9.2-6.fc27.x86_64
  - cannot install the best update candidate for package gstreamer1-plugins-bad-free-1.12.4-1.fc27.x86_64

This does not remove any packages when running dnf update or using gnome-software. dnf shows this by default:

Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 soundtouch                              x86_64             2.0.0-3.fc27                   updates               72 k

Only if you use --best --allowerasing, then it erases a lot of packages. I would be interested to know how this can happen to anyone by accident (is there a use case I'm missing?).

I believe the rpmdeplint test didn't catch this, because it currently only runs rpmdeplint check-sat. And this RPM is installable, it's just incompatible with a lots of RPMs that people have on their system by default. If we also ran rpmdeplint check-repoclosure, it should catch this (IIUIC), but we haven't implemented that yet (here's the ticket for it).

Abicheck should have caught this, I think. @dodji, can you please look into why it hasn't?

@jwrdegoede do you have a proposal for Fedora to decide on?

@till, no I just wanted to bring this issue to FESco's attention.

Metadata Update from @psabata:
- Issue tagged with: meeting

5 years ago

At the meeting today we decided to close this issue. Thanks for bringing it to us.
If you believe there's something to investigate and/or fix, file it with Fedora QA.

Metadata Update from @psabata:
- Issue untagged with: meeting
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata