On Thu, 2014-01-16 at 17:00 -0800, Russ Allbery wrote: > Uoti Urpala <uoti.urp...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
