Latest updates are missing a dependency

Bill Davidsen davidsen at tmr.com
Fri Oct 2 22:15:36 UTC 2009


Rex Dieter wrote:
> Tom Horsley wrote:
> 
>> On Wed, 30 Sep 2009 15:51:52 +0200
>> Michael Schwendt wrote:
>>
>>> Skipping the updates-testing repo and pushing updates directly into the
>>> updates repo is frowned upon.
>> I still can't understand why the repo update process isn't automated
>> at least to the extent of testing updates on a virtual machine
>> which has all optional packages installed to see if the updates
>> install correctly and the system still boots after the updates.
> 
> It's known, but implementing this is *hard*, and there are concerns how it 
> could impact the speed/performance of performing updates.  Pushing updates 
> as-is already is a multi-hour operation, mind you.
> 
I would hope that the time is proportional to the size of the changes, so 
preventing sending of something broken would (or should, or might if you prefer) 
avoid sending broken once and fixed later. That applies to the follow paragraph 
as well.

> OK, so a broken dep is found somewhere, now what?  Stop the presses, 
> manually find what is broke, restart updates-push from the beginning?   Not 
> fun.  Hopefully, this scratches the surface to communicate how this is very 
> much a non-trivial thing to do.
> 
> Now, if you're interested in helping to make this a reality, I can help 
> facilitate getting in touch with those on the rel-eng side.
> 
If it would help to catch the low hanging fruit by testing many of the updates, 
it could be fairly easily done, although it would take a bit of machine effort 
to run the test. Consider that changes in updates-testing would be subject to 
some automated sanity check:
1 - create a qcow2 copy of the current sane VM (updated to yesterday)
2 - boot it
3 - have rc.local or similar download a list if packages to install or upgrade 
over the network (this proves the network worked to start).
4 - run yum and install/upgrade the packages involved
5 - reboot
6 - if the system comes up send a message over the network saying it passed the 
smoke test (proves the network still works).

Caveats:
- it doesn't test changes which break other network drivers or wireless
- needs to be run on each primary machine type
- doesn't test if the upgrade does what it should
- doesn't test display breakage

But it does test being able to apply the upgrades and have a sane system. And 
that would have caught the latest few dependency issues, and saved a LOT of 
hassle. It would allow things to be kicked out of the process without false 
positives.

-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot




More information about the fedora-list mailing list