On 17 January 2014 03:52, Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: > What is Debian ? In one respect, Debian is an operating system. And > of course in another respect Debian is a community. > * Debian is a forum for cooperation and technical development. > * Debian, as a piece of software, tries to be all things to all > people (within reason).
So the original message referring this to the tech ctte was about deciding on "the default init system". Honestly, that seems like the least interesting part of this discussion to me; and I wonder if the ctte shouldn't consider answering some different, but related question that more directly addresses issues like packages depending on cgroups or logind. Something like: a) maintainers should be aware cgroups is a Linux-only feature; if their package requires the use of cgroups to be usable it should be configured to not build for non-Linux architectures. b) maintainers should be aware systemd relies heavily on cgroups, and thus should be aware that requiring use of a systemd unit file for startup will likewise require their package to be configured to not build for non-Linux architectures. c) logind or an equivalent service implementing the freedesktop.org systemd/logind api should be available under all supported init systems and architectures in Debian. It should be provided via a virtual package "fdo-logind" and packages (such as desktop managers) expecting logind to be available should Depend on fdo-logind d) [are packages likely to start depending on localed/hostnamed/timedated/machined/??? in the same way as logind such that it would need to be available outside systemd for upstart to be a useful init?] e) no init system in Debian should be marked as Essential:yes, or depended upon by any Essential:yes or Priority:required package except through the virtual package "init-system". All init packages should Provide: and Conflict: init-system. base-files should Depend: init-system. f) all init systems Providing the init-system virtual package must support packages providing sysv style init scripts via update-rc.d. g) packages that do not work with sysv must declare a Depends: on the init systems they do support, eg upstart | systemd h) having examined the various current available init systems, the tech ctte considers [OpenRC] to be the best available init implementation at present, and so determines that the relevant maintainers, including the installer team and ftpmasters se it as the default init-system for new Debian installs. This decision becomes vacant should a general resolution specifying an alternative init system as the default pass with a simple majority prior to jessie's release. i) all these decisions revert to advisory opinions after the release of jessie, and may then be changed by the usual methods of consensus driven policy development, and maintainer decisions, or by referring the issue to the tech ctte again. I think (a) and (b) are pretty non-controversial. (c) and (d) are required if we want to deal with new GNOME stuff and anything other than systemd probably, and don't seem very hard to either do or document. (e), (f) and (g) seem like a fairly straightforward of allowing for multiple init systems in Debian. I think something like (i) might be a good way of sunsetting tech ctte decisions so if there's an actual consensus in future, there's no need to get a pro-forma vote from the ctte to make changes in future. YMMV of course. In my ideal world, the tech ctte would work out good answers to all the bits above except (h) and get those added to policy, then propose various options for (h) as a GR themselves, with well argued rationales for each of the options along the lines of what's already been posted to the list. How much that conflicts with the "No detailed design work" portion of the ctte's mission statement is up for debate though. Why you'd have a *technical* committee and forbid them making sure the "details" are right doesn't make a lot of sense to me though. Fortunately I'm not on the tech ctte list, so I can look into details all I like ;) Cheers, aj -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajs_lcxtps1xdy6owf6eqwz5jwujccj0sio8kadakqwv2k8...@mail.gmail.com