2012/2/5, Aurelien Jarno <[email protected]>: > The problem there is that given that all 9.x packages have been already > pushed to the archive with ABI changes and so on, we *must* switch the > default kernel for wheezy to 9.x.
This is not really the case. We can switch the default [1] kernel if we want to, or we can add 9.0 compat glue to 8.x kernel. [1] For a very loose meaning of "default". User selection is still very explicit. > I don't say it's a bad decision, but > I would have prefer to have some discussion about, it including the > possible consequences of such a choice, instead of getting to the point > of not having any other choice. I would have preferred that, too. This is why I asked whether it was a good idea to upgrade kfreebsd-kernel-headers to 9.0: http://lists.debian.org/debian-bsd/2012/01/msg00057.html I only realized that freebsd-utils 8.x [1] wouldn't build with the new headers about 3 weeks later, after several hours of trying. I wish someone had told me. At that point packages were already building against 9.0 headers and we had no way to turn back. [1] Yes, freebsd-utils. Of course I _did_ test freebsd-libs 8.x with the new k-k-h, but freebsd-libs 8.x had no problem because it duplicates the whole thing and was silently using its private copy of kernel headers. Too bad I only run into real trouble when attempting the upgrade of freebsd-utils to 8.3~snapshot, which required a small change in libcam API. Then I tried cherry-picking that change, and it kept dragging more things in. Eventually it was unmanageable. And yes, I wish someone had told me to test freebsd-utils first. I guess if noone said this it's simply because nobody knew. FWIW, I'll see if freebsd-libs can be fixed to use system k-k-h instead of duplicating everything. > Now we have no choice than making a real plan for switching to 9.x > kernel: > - We have to make sure users are using wheezy/sid with a 9.x kernel. > - We have to provide an upgrade path for users, including the best > moment to switch from one kernel to another in the release notes. You're missing a bigger part of the problem: fixing runtime problems in userland that are only exposed by kfreebsd-9. Overall I wouldn't recommend making 9.x "default" if we can avoid it. The only problem with kfreebsd-8 right now, that we know of, is CAM. And it's not a severe problem (camcontrol effect on average user is only cosmetical), nor a hard problem (see #658617). > - The build daemons are going to stay with the 8.1 kernel up to the > release of wheezy. Will it work? Sounds like a safe bet to me. > Sometimes after they are going to > switch to a 9.x kernel, but they should still be able to build squeeze > packages. Will it work? kfreebsd-9 is unusable on Squeeze. After glibc 2.11.3-1 upload this got much better but there are still incompatibilities with sysvinit and with ZFS v28 userland. > Who wants to work on addressing these points? I don't like the incriminatory tone of this mail. I'm just trying to help here. When I run into a complex decision, I ask the list for advice, most of the time I don't get any of. But I try anyway, because I think advice is valuable. Oh yes, I wish people had participated in that discussion, as with many others. But I don't blame anybody, I don't point at them. People are busy. It's ok really. But I'd rather have a productive discussion than a useless rant. Can we argue about how to solve things? My advice is not to make this any bigger than it is: The only kernel<->user problem we know of is an incompatibility in CAM, which has a low impact and is not hard to fix. I don't recommend trying to declare kfreebsd-9 as fully supported because that smells like a lot more work than simply cherry-picking a few commits into kfreebsd-8. -- Robert Millan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/caofdtxnno8xfyegtsahn+xdhzrcua2axmvug4pukcfbcb_0...@mail.gmail.com
