Alsa-utils update broken

Michael Schwendt mschwendt at gmail.com
Thu Feb 16 11:17:22 UTC 2012


On Wed, 15 Feb 2012 19:45:11 -0500, TH (Tom) wrote:

> On Wed, 15 Feb 2012 23:40:22 +0100
> Michael Schwendt wrote:
> 
> > Of course, a temporary staging repo would be needed. Filling it isn't
> > trivial, however, and requires lots of iterations and a bullet-proof
> > "--skip-broken" finder
> 
> Huh? None of that junk is in updates today, that's why people
> find it broken all the time. The test system using the staging
> repo can either run "yum update" with no errors, or it can't.
> If it gets no errors, the staging repo becomes the updates
> repo. If it does get errors, the updates repo is left alone
> until the staging repo gets fixed and everyone who pushed
> an update since the last time updates was working gets mail
> with the yum update transcript.
> 
> Yes, that means nothing goes in updates if even one thing
> is broken in the staging repo. But that is NOT a problem.

Well, we can agree, if what you propose would happen at an earlier
stage. To prevent broken deps in updates-testing already. With the added
complexity that if any published package doesn't pass the testing and gets
removed, any dependencies in other bodhi tickets must be removed, too.

Bodhi then would refuse to accept any tickets, which break dependencies.
That would imply that any push to stable could be free of broken deps,
too, since it would only be a matter of resolving dependencies and adding
the needed packages into the transaction set.

Packagers could not simply publish incompatible library upgrades, for
example, without publishing corresponding updates for dependencies on
those libs. The update-testing request would need to be _complete_ before
bodhi would accept it. Sort of an extra hurdle, however, and could be
considered tiresome bureaucracy (because of the packager/advanced-packager
model, where only the advanced-packagers are permitted to touch arbitrary
packages and create bodhi tickets for them, too).


So, I think it's a bug, if updates-testing contains broken deps and if
packagers are permitted to keep such packages in updates-testing.
Working on repositories, in which dependency breakage accumulates, gets
increasingly troublesome. I'm not sure that would scale. It would need an
environment where arbitrary packagers can alter all pending updates (to
fix broken deps or to delete them) and trigger a new push to stable. Else
it could become a pain to publish security fixes or packages with
inter-dependencies on buildroot overrides.

> Virtually everyone trying to run "yum update" with the current
> process is getting errors and giving up till things work
> anyway.

I'm more concerned about the regular plea for help by those users, who
don't just wait till updating works again. In replies, they receive wrong
advice, such as enabling the updates-testing repo, running "yum clean all"
(even if they use only the graphical package tools), or forcefully
removing or reinstalling packages, which sometimes "fixes" the issue only
because the repo has been fixed meanwhile. Or they don't get educated
about the severity of the symptoms they see.


More information about the users mailing list