Bug#727708: On diversity
On Thu, 2014-01-16 at 17:00 -0800, Russ Allbery wrote:
> Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
> > I think the divergence has gone too far in things like non-Linux ports.
> > They have had an overall negative effect on people working on Linux
> > within Debian and people creating derivatives.
>
> I have to take exception to this. There has been a great deal of
> *concern* from people over the past two years that the non-Linux ports
> *might* have a negative effect on Linux in the context of this particular
> discussion.
I consider the effect on the init system decision process so far to
already be an example of actual negative effects. Even if it does not
ultimately lead to an inferior system being chosen for Linux (which
would be a major harm), the portion of discussion that has been about
non-Linux ports has been completely out of proportion compared to their
potential benefit/importance, has made the decision process harder, and
has made it more difficult for anyone else to follow the discussion or
form an informed opinion based on it.
> But, in the meantime, the non-Linux porters have been
> first-class Debian contributors over the years. They have not
> substantially gotten in the way of Debian's processes, certainly no more
> than any Linux port to a more obscure architecture,
I don't have any numbers, but I would be surprised if that "no more
than" were true. The kernel and compiler already abstract away most of
hardware differences, and ignoring toolchain issues, I'd expect most of
hardware-specific failures to be things that could be considered general
bugs in the software even on platforms where it works. By comparison,
changes required by kernel differences are generally not positive on
other platforms.
> and they have
> contributed a great many improvements to our software.
>
> For example, I think special thanks should go to the Hurd porters for
> extended, thankless work on removing static buffers from the code in the
> archive. They were doing so because some of the constants used to size
> those buffers are not portable to the Hurd, but using static buffers to
> store paths and related strings is often incorrect regardless of its
> portability, and can even be a security issue depending on how the code is
> written. The Hurd porters have provided reasonable patches that can go
> back to upstream and result in objectively more robust software. I have
Those are probably among the most useful patches, but I think they're
still very minor, and not worth the maintainer work adding distro-
specific patches in Debian (as opposed to letting it become part of
upstream code). Most changes will not be useful on other kernels.
There are also other costs. For example, kFreeBSD issues have prevented
testing migration of packages. Even if systemd is chosen as Linux init,
will everyone packaging daemons or other software interacting with init
for Debian be expected to remember guidelines or even do things
differently because of issues that only matter for non-Linux?
"zgrep -i kfreebsd /usr/share/doc/*/changelog.Debian.gz" shows over 1000
different matches just on this machine. Of course some of those packages
could be maintained by people who personally really wanted to work on
kFreeBSD regardless of its value, but I doubt the majority is. IMO
justifying that amount of work, and claiming that kFreeBSD has not had a
negative effect, requires showing some concrete benefit.
Reply to: