On Sun, 20 Aug 2006 12:25:39 +0200, Thorsten Leemhuis wrote: > Let's say the current kernel is kernel-2.6.16-1.2133_FC5. kmod-foo and > kmod-bar are in the repo for that kernel. kernel-2.6.17-1.2139_FC5 get > pushed out. kmod-foo build fine for the new kernel and gets pushed to > the repo. But some API changes in the 2.6.17 kernel break kmod-bar. The > upstream maintainer of bar is lazy and says "it'll take some time until > it'll get fixed." So people depending on kmod-bar will stick to the old > kernel. Now lets further assume kernel-2.6.17-1.2145_FC5 get pushed some > days later and contains an important security fix that's remotely > exploitable in 2.6.16 and 2.6.17. The users of kmod-bar are in trouble now. IIUC, we have to choose between to evils: - users left out in the cold because the kmod they use is not updated on a timely basis - users left out in the cold because we refuse to accept any kmod Doesn't sound like a fun choice. I'm pretty sure such a choice could happen with other pieces of software, though: - web browsers and their plugins - mail/news readers and their plugins - probably other large pieces of software and related add-ons Do we want a special repo marked "DANGER, caveat emptor" in big red letters ? Christian _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board _______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
