>> I'm coming round to the view that we should be planning to support >> multiple systems indefinitely. > This has been my opinion all along. Various assertions that it's > somehow just too hard really haven't swayed me. The tricky bit, I > think, is to define just what "support" means in the context of > non-default init systems. Too hard is a lousy defined thing. But it is an enormous amount of extra work added to all maintainers of packages with init $things. They basically get pressed into maintaining three widely different ways of starting their daemons. It's nice to say "community of $system will support it", but does anyone really believe that whichever of the X (currently 3) communities commit to maintain their systems init $things in all our packages? Maybe in a very ideal world, but thats not where we are in. Likewise I think one can forget the porters of an arch to do so. The only way, IMO, to really support this way would be to come up with something like our menu support. The maintainer puts a metafile somewhere, triggers let the installed init system know there is something new, and it converts that metadata into a working init $thing. And the maintainers of init systems have to, similar like the window manager ones had to, come up with the converter metadata -> init $thing. And yes, I realize that lets a lot to be desired. Starting with "WTH to do with software that really needs one over the other systems?" and a lot more points, which all had been mentioned times and again. As much as it may be hated, a clean decision "this is it, the rest is officially not supported", no matter for which of the candidates the decision goes, is IMO the best for the project longterm. -- bye, Joerg Ubuntu: An ancient african word meaning "I can't configure Debian"
Attachment:
signature.asc
Description: PGP signature