Thorsten Leemhuis wrote:
Kernel, X.org and other userland drivers (like hpijs, gutenprint,
sane,...) should normally be updated "quickly" (*1) to the latest
version in the latest stable Fedora release if the new version improves
hardware support. In cases like X.org 7.1, where the update might break
important non-Fedora stuff (like the proprietary drivers from nvidia),
we need to discuss how to proceed. Maybe setting up a special repo that
has the newer X would be the proper solution *until* the non-Fedora
stuff is fixed.
(*1) = read quickly as: Push the stuff to rawhide. Wait one week. If
everything looks okay push it to updates-testing for a week. After that
week move to updates proper if no big breakage showed up in between.
Does that sound sane?
That model works for the kernel partly because the kernel happens to be
one package. X is many. This is broadly a feature, but it does make
mass updates like the 7.x katamaris slightly stressful. Brew is
unhelpful here because when doing katamari rebuilds I need to force
package A to build against the very newest package B, and there's no
mechanism for me to say "update the buildroot _now_ dammit". I'm told
that's coming though.
- ajax
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
