Re: systemd bug closed - next steps?
-----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-----
Reply to: