Bug#780403: debian-policy: Define what should happen when installing a package and the init script fails to start it
On Wed, Apr 15, 2015 at 02:51:11PM -0400, Sam Hartman wrote: Russ == Russ Allbery r...@debian.org writes: Russ Ivan Baldo iba...@adinet.com.uy writes: What should happen if installing a package and then when it tries to start its service it fails? Currently the most common behaviour seems to be that the installation fails. But is that the best outcome? Russ Currently, Policy leaves this to the discretion of the package Russ maintainer. To change that, what will be needed here is not Russ just an argument that other behaviors besides failing Russ installation might be desirable, but that there is a Russ compelling need to standardize this behavior across the entire Russ archive instead of leaving it to the discretion of the Russ maintainer. I find this issue tends to come up a lot more than it used to. The issue is that systemd units tend to track a lot more errors than init scripts. So, in Jessie, there tend to be a lot more cases where a package will fail to install under the same situations where in wheezy it'd install fine. The problem is made more complex by debhelper, which makes it somewhat annoying (especially in dh 7 mode) to express this maintainer preference. So, you have a lot of dh7 packages that suddenly got much more picky because people created service units. In general, packages maintainer scripts should not fail without a compelling reason. A package installation failure leaves the packaging system in a state where it is much harder to recover from problems. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780403: debian-policy: Define what should happen when installing a package and the init script fails to start it
Russ == Russ Allbery r...@debian.org writes: Russ Ivan Baldo iba...@adinet.com.uy writes: What should happen if installing a package and then when it tries to start its service it fails? Currently the most common behaviour seems to be that the installation fails. But is that the best outcome? Russ Currently, Policy leaves this to the discretion of the package Russ maintainer. To change that, what will be needed here is not Russ just an argument that other behaviors besides failing Russ installation might be desirable, but that there is a Russ compelling need to standardize this behavior across the entire Russ archive instead of leaving it to the discretion of the Russ maintainer. I find this issue tends to come up a lot more than it used to. The issue is that systemd units tend to track a lot more errors than init scripts. So, in Jessie, there tend to be a lot more cases where a package will fail to install under the same situations where in wheezy it'd install fine. The problem is made more complex by debhelper, which makes it somewhat annoying (especially in dh 7 mode) to express this maintainer preference. So, you have a lot of dh7 packages that suddenly got much more picky because people created service units. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780403: debian-policy: Define what should happen when installing a package and the init script fails to start it
Ivan Baldo iba...@adinet.com.uy writes: What should happen if installing a package and then when it tries to start its service it fails? Currently the most common behaviour seems to be that the installation fails. But is that the best outcome? Currently, Policy leaves this to the discretion of the package maintainer. To change that, what will be needed here is not just an argument that other behaviors besides failing installation might be desirable, but that there is a compelling need to standardize this behavior across the entire archive instead of leaving it to the discretion of the maintainer. I think it might be better to start with filing bugs against the specific packages that you want to run in non-standard configurations, where the abort on service start failure behavior is interfering with your ability to do that, and then see what the package maintainers say. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780403: debian-policy: Define what should happen when installing a package and the init script fails to start it
Package: debian-policy Severity: wishlist What should happen if installing a package and then when it tries to start its service it fails? Currently the most common behaviour seems to be that the installation fails. But is that the best outcome? What if the sysadmin has a reverse proxy listening on port 80 and then decides to install Apache or Nginx? The init script fails until it changes the port to 8080 for example, but shouldn't the package just install fine anyway? It could be said that a failure to startup is not a failure to install; the package is installed fine but configured wrong. What if one wants to install Nginx as a frontend to static files and delegate dynamic pages to Apache? Maybe for the sake of flexibility and not so standard setups, init script failure could be defined to not cause install failure. For example, change this in postinst: invoke-rc.d service start || exit $? to this: invoke-rc.d service start || true See for example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779825 Thanks for considering! Have a good day. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=es_UY.UTF-8, LC_CTYPE=es_UY.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
