El 5 de febrer de 2012 14:57, Petr Salinger <[email protected]> ha escrit: >> You're missing a bigger part of the problem: fixing runtime problems >> in userland that are only exposed by kfreebsd-9. > > There might be similar problems with using backported parts in 8.x.
The impact of that is very much smaller. For example the issue at hand (backporting CAM) only affects applications that use CAM, whereas 9.0 taken as a whole has potential for breakage in broader classes of general-purpose apps (we've seen this with the LD_PRELOAD / AT_* issue for example). >> 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. > > The eglibc update is not necessary, it should suffice to enable > 007_clone_signals.diff in kfreebsd-9. Well, now that 2.11.3-1 is in Squeeze I think it's not worth bothering with, since a simple dependency will drag the required libc in any Debian GNU/kFreeBSD release. >> 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. > > All from 9.x serias seems be better especially in long term. I don't mean to argue against that. If I can choose I'll probably use 9.x in some systems and stay with 8.x in others. However how does this affect the overall work? Declaring kfreebsd-9 as the "good" platform would make it easier to fix some bugs and/or port some packages, etc? We need to keep in mind the restrictions with buildd's. I'm unsure if we can make kfreebsd-9 runtime a requirement for building packages. Currently it's not even usable on Squeeze in many situations. In terms of manpower providing both seems like the cheapest option to me. Then we'd just have to garantee "full support" (for building packages, etc) in kfreebsd-8, and make sure kfreebsd-9 is basically usable. With enough time (e.g. a full release cycle) it'll be easier to assess what are the actual problems with kfreebsd-9 and how much work is required to fix them. -- Robert Millan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAOfDtXPd570YfwLwHKWxQqhzPjM2v=vtgz1kmczjrss3typ...@mail.gmail.com
