On Mon, Jul 22, 2013 at 07:17:04PM +0300, Uoti Urpala wrote: > brian m. carlson wrote: > > Since Debian is always in need of developers and volunteers, it isn't > > objectively reasonable to expect that forking a project will be > > possible. One thing that needs to be taken into consideration is the > > *likelihood* that upstream will take development in an undesirable > > direction, or in a direction that is not acceptable for Debian. > > If you don't do development, and nobody sharing your views does either, > then there's a limit to the extent you can choose your direction just by > refusing to follow those that do develop things further. You can't stick > with Minix forever even if you think the direction of Linux is > undesirable. My point is that Debian developers create lots of great software, and certainly maintain lots of patches to software for which Debian is not upstream. But it's simply not feasible for Debian to be the upstream for all software. I don't think it's controversial to say that Debian developers prefer upstreams that take concerns relevant to Debian and its users into account. > Suppose that in the future systemd does go in a direction you don't > like. Now would it have done any good for Debian to not adopt it? Not > really, if nobody develops a competitive alternative to its > functionality. Not using it would only make Debian obsolete for most use > cases. And the most realistic way to create a competitive alternative > going in a different direction would be to fork systemd, so adopting > current systemd would not make moving to such alternatives harder. The vast majority of the work I do on a Linux box, desktop, laptop, or server, does not involve init in any way. It is therefore not accurate to claim that using an init system other than systemd would make Debian obsolete. For example, RHEL 6 and Ubuntu use upstart, and I think it's hardly accurate, based on their significant adoption, to call them obsolete. > > For example, if an upstream expresses disinterest in supporting non-PC > > architectures, that may be a bad piece of software for Debian to place > > in an important role, even if it currently works on all our > > architectures, since Debian is very portable among different > > architectures. > > Of course, this isn't relevant to systemd, as it has no hardware- > specific code and supports embedded platforms for which Debian is too > bloated. This was meant as an illustrative example of a common problem with upstreams, not as a problem particular to systemd. systemd upstream has made a lot of controversial decisions that Debian may or may not want to support: combined / and /usr, the journal, logging to the kernel ring buffer, lack of portability to non-Linux kernels, and merging udev and systemd are a few examples. If Debian decides that it is preferable for whatever reason not to adopt one or more of these decisions, the willingness of upstream to accept that decision and work with Debian instead of saying, "Too bad, so sad," is something that should be considered before making a major change. I'm not saying not to use systemd, I'm just suggesting making a well-reasoned decision. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Attachment:
signature.asc
Description: Digital signature