Simon McVittie wrote: > The point at which kFreeBSD or Hurd might harm Debian's universality is the > point at which supporting them causes problems for the rest of the project.
That is the crux of the issue. I think that if we find ourselves being
held back by needing to support kfreebsd or the hurd, a good question to
ask is:
If we had made this change before the kfreebsd port was released, would
it have somehow prevented that port?
My experience in Debian is that we adopted a great deal of linux-specific
technology over time, without much concern for whether it would cause
difficulty for unreleased ports (eg hurd). For example, d-i took
advantage of heavily linux-specific devfs[1] and was generally developed
without any particular care about portability. And yet this rather
massive weight of linux-specific choices did not prevent the kfreebsd port
from happening. It just made that port more of an impressive achivement.
So it seems unlikely to me that many changes would run afoul of the
above question, if every change made during Debian's history so far has
not managed to block the port. I'm hoping to see us go full ahead with
the linux-specific stuff. While still maintaining easy portability where
possible, in our best tradition of harnessing multiple architectures to
improve overall quality. And having the hard portability issues dealt
with by the port's dev team.
(The corollary BTW, is that we should take full advantage of freebsd-specific
features inside that port. Eg, running daemons inside jails or whatever.)
--
see shy jo
[1] which turned out to not have legs, but then we just switched to the
linux-specific udev instead :P
signature.asc
Description: Digital signature
