On 05/27/2017 11:37 PM, Ivo De Decker wrote: >> Well, there is also ulibc being shipped with Debian stable. Yet, when >> someone tries to use it and breaks their system, it's not supported >> either. So, I don't think this policy can be sweepingly applied to >> every package. > > There is no package named 'ulibc', so I guess that's a typo. If you meant > uclibc, that package only ships uclibc-source, so installing that doesn't > break anything.
Is it really relevant for the discussion whether I made a typo or not? My point is: There is a package called uclibc-source that people can install the source from, compile and install to completely hose their system. Simply because the C library is such a fundamental component of the system that it cannot be trivially replaced. To use the popular car analogy: Replacing the installed radio with a third-party radio will work for most people without issues. However, replacing the gearbox will probably a lot of more headaches and requires advanced technical skills and knowledge. >> I fully agree. However, runit is one of the packages which is not >> automatically removed. > > No. But it can be manually removed. Then please let's do this. I already saw it was marked for that which is good. >> You really cannot expect a fundamental component like an init system >> to be easily replace by the end user the same way they can swap their >> default text editor. > > Well, in that case there shouldn't be a package that tries to swap the init > system. If there is a package that provides the tools to do so, but lets you > do it on your own, that's a different story. It will still allow you to break > your system, but you can do that with lots of tools (certainly with your text > editor). Uhm, the package is an alternative init system. Of course, it will try to replace the init system. What else is it supposed to do? That's one of the reason I am completely opposed to ship alternative init systems and the other relevant Linux distributions like Fedora, RHEL, SLE(D,S) and openSUSE only ship systemd either. Being such a critical component of the whole stack, it simply will never be able to trivially swapped out without breaking lots of things. Hence this bug report is completely moot. When people like the original bug reporter want to replace the init system, I assume they know what they are doing so they should be able to clean up the mess afterwards. Or do you let layman replace the carburetor on a car themselves without the proper skills and knowledge and then accept when they complain that something broke in the process? Really, things like the init system, the C library, the default compiler and the kernel are *not* user-servicable parts. If you don't know what you're doing, don't touch them and don't pester the maintainers with pointless bug reports. Plus, we also clearly decided in 2014 with the CTTE decision and the follow-up GR by Ian Jackson that we do not care about alternative init systems. > As there doesn't seem to be an easy way to get an acceptable runit-init > package, which replaces the init system by just installing a package, I don't > see how the current src:runit package can stay in stretch. If someone wants to > keep it, the best option is probably to remove the runit-init binary package, > so that the other binary packages can stay. As Roger noted, that would require > an NMU to do so. The same problem will apply to sysvinit, openrc, filerc and whatever other init system we have packaged in Debian as well. I don't want to test that myself right now, but I am 99% confident that installing the openrc package will let you with the 'poweroff' and 'reboot' commands broken until you perform a hard reset. > I'd be happy to unblock such a change (if it happens in the next few days, > given the release timing announced in > https://lists.debian.org/debian-devel-announce/2017/05/msg00002.html). Thanks, but no thanks. I'm happy to provide patches and perform NMUs for all kinds of packages. But I'm not touching any of these alternative init systems because I consider them a complete waste of time. There is simply absolutely no technical justification to ship multiple init systems. If someone wants to use runit or any of the other init systems, they should take care of such issues themselves and not bother other people with that. There are more important issues to work on. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
