Re: Bug#658185: freebsd-9: freebsd-9 kernel + smartmontools:
El 5 de febrer de 2012 14:57, Petr Salinger <Petr.Salinger@seznam.cz> 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
Reply to: