3 ms·

From what I gathered following the discussion the problematic option was actually "no package that depends on systemd and does not provide an alternative that w

From what I gathered following the discussion the problematic option was actually "no package that depends on systemd and does not provide an alternative that works with sysV is permitted". That would require that somebody provides the code to make the alternative way viable, work that neither the upstream would do nor the maintainers were willing to shoulder. It's fine to make that demand, but if you do, IMHO you should also step forward and say "and because this is what we propose, we will be providing said code."

teddyh 12y ago
Yes. Saying “We permit systemd to exist in Debian, but we will not permit any packages which uses systemd’s extra features or advantages.” is hardly a compromise.
- wtbob 12y ago
  Neither, of course, is saying, 'we will permit packages to fail to work with any init system other than systemd.'
  - Xylakant 12y ago
    why not? If a package leverages functionality that only systemd provides and users want to have install package, they have to bite that bullet and install systemd. What are the alternatives? You can't force the upstream or the package maintainer to invest the extra work to make the package work without systemd, you're not providing the required work either and you certainly don't want the user to be on the loosing side because you don't like systemd.
    - lmm 12y ago
      > you certainly don't want the user to be on the loosing[sic] side because you don't like systemd. Debian has a long and glorious tradition of standing on principle to the user's (at least short-term) detriment. Look at the way they used to ship KDE programs (especially in the days before GPLed Qt), or the way they still package tomcat, or their approach to multimedia codecs.
  - teddyh 12y ago
    Why not? This thing here, where a package fails to work without another specific package, is called a dependency, and that is is the normal way to do things. Just because you don’t like package A does not allow you to “compromise” by allowing A but not allowing B, C or D to have a dependency on A.

teddyh 12y ago

Yes. Saying “We permit systemd to exist in Debian, but we will not permit any packages which uses systemd’s extra features or advantages.” is hardly a compromise.

wtbob 12y ago
Neither, of course, is saying, 'we will permit packages to fail to work with any init system other than systemd.'
- Xylakant 12y ago
  why not? If a package leverages functionality that only systemd provides and users want to have install package, they have to bite that bullet and install systemd. What are the alternatives? You can't force the upstream or the package maintainer to invest the extra work to make the package work without systemd, you're not providing the required work either and you certainly don't want the user to be on the loosing side because you don't like systemd.
  - lmm 12y ago
    > you certainly don't want the user to be on the loosing[sic] side because you don't like systemd. Debian has a long and glorious tradition of standing on principle to the user's (at least short-term) detriment. Look at the way they used to ship KDE programs (especially in the days before GPLed Qt), or the way they still package tomcat, or their approach to multimedia codecs.
- teddyh 12y ago
  Why not? This thing here, where a package fails to work without another specific package, is called a dependency, and that is is the normal way to do things. Just because you don’t like package A does not allow you to “compromise” by allowing A but not allowing B, C or D to have a dependency on A.