-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/21/2014 at 12:12 PM, John Hasler wrote:
> Rob Owens writes: > >> I submitted a general bug regarding packages which require >> changing your init system to systemd. I pointed out that this >> runs counter to Debian's goals of supporting multiple init >> systems. > > No, it doesn't. Any individual package can depend on any other > package. Unfortunately, many upstreams are writing their code in > such a way as to require that when their software is packaged for > Debian the resulting package must depend on systemd features. How does this contradict the idea that having packages which require the use of a particular init system runs counter to the goal of supporting multiple init systems? The problem is specifically that the features which these upstreams want to depend on are provided by an init system. That should be rejected out of hand; any functionality which a separate project might legitimately want to depend on should not be provided (primarily or exclusively) by an init system, unless all init systems will necessarily provide that functionality. Filing bugs about that against the packages which depend on that functionality, as advised in the mail closing the bug which this thread is about, is not productive; they don't control what provides the functionality they need. Filing bugs about it against systemd - either in Debian or upstream - would be getting closer to the root of the problem, but would also not be productive; providing these features in the init system is an intentional design choice of systemd. It is also exactly what should be changed, but good luck getting anyone in the systemd project to agree to the idea of changing it. > The only solutions for this are to either convince upstream > authors to change their ways or to make other init systems able to > emulate systemd to the extent necessary. > > If you can find packages that gratuitously depend on systemd file > specific bugs against those packages. When the systemd dependency > is deeply embedded in the upstream source, though, there is > nothing the package maintainer can do about it. Just because there's nothing the (depending) package maintainer can do about it doesn't mean there isn't a bug, though. As I've argued before, the bug lies in the design stage, specifically in the decision to implement certain functionality in systemd rather than outside of it. The resulting behavior, in terms of packages which are not related to a particular init system but which will only work with that init system present, is undesirable and unnecessary - which seems like a decent enough mapping to "buggy", at least to me. Saying "Yes, it's a problem, but there's nothing we can do about it" would be one thing (although there *is* something which could be done about it, in terms of pushing back on systemd upstream). But saying "This isn't a bug" is very much another. - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUHwLCAAoJEASpNY00KDJrNzkQAIkrqWa/n001Yasrlb+E860N lrk71gSlESdOAvOR+iuxoYdi8E6F//ADuAePuSH4a9vxg6U9UiL80KjL9IZn2CGO cCbPRv+XqENsdmAFKXPVNZikxPG5Tien+YW8uHUWApnUDGa3lQoZiJr98A+1LaP/ Ga2kChuJDYKhCR1ceKoz710xPGvjqrp7jYl4H5l1I8nBpDw0omm3MBaGX4US5ugy bNWgN7MAMstUR44RMZCVHEsI3+SgjynQ4UW0nDQ+6MuVMY2ZacRHQx1M4aubZVvH 0QcOwLi3livCvuQvjXFMzrKprBr/iisWk18BTug8Fp+2vP12i+XgzdUDaegKdBGu 5DDPnwqqcC1kXZsWdRPA/1A1fNlsp1stVQyygYfQhtj2p20PMc1esOKIE/PHp246 84sbwtKH8SGoWlgVRZUNsosF4qbMjg0gznXqtk3V0LxYN2O0/oqZDk2iHJ7iwcuY fSkX/Ps8dH5N+N6kQkAFcQPjwJsUBriXaGA7zSWL+HuJChcJ6FYy877YsTQL75Lj 22JAJwaCO2Ml8PmLS4U+jLEvV7hK0OAiPDrR808T1Q13JmgRLS1XibvWyQTfko2l YnwjrC8bxkHnSZiWpPyU6s+s2JkGPvEHxiQvmpcVrW4oz9Nlyq2zNLYqpyR6DwXq 2JiCDfkEpC1yvHExMfuh =tWIr -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541f02c2.2040...@fastmail.fm
