control: reopen -1 On Thu, Dec 25, 2014 at 11:25 AM, Steve Langasek wrote:
Hi, Thanks for the feeback. > This is not a reasonable thing to ship in any package in the archive. There are other packages that already do this. In fact one of the motivations for *.d directories in etc is this exact purpose, which is for packages to reliably alter behavior of others in specific allowable ways. Some examples of packages using apt's preferences.d (in a lot of false positives): https://codesearch.debian.net/results/apt%5C%2Fpreferences%5C.d/page_0 Interestingly, python-diskimage-builder does the opposite of the discussion here. It pins sysvinit at -1 to try to ensure a systemd-only system (although they should really use sysvinit-core now). > Pinning should be managed directly by the admin; wrapping this in a package > is an unnecessary indirection. The thesis of that statement casts abstraction as always to be avoided, but abstraction is one most important and core tenants of computer science. It's what makes computers useful. Imagine if we said no to all abstraction, the only way to operate a computer would be flipping switches or typing assembly. That would be far less fun. > The actual contents of your pin are also highly harmful to the user, and > will prevent upgradability of large numbers of packages that take advantage > of systemd facilities. Behavior that can easily be reverted by removing a package seems like the opposite of harmful. It is more of an empowering abstraction for the user. Install the package -> no systemd, remove the package systemd is allowable. No need for the user to educate themselves on the details of pinning. But more importantly, it solves a thorny political issue via a simple technical solution, and obviates the need for a certain kind of showboating over such simple problems [0]. > The way to express that you want to retain sysvinit > as the init system would be to pin the systemd-sysv package *only*, not any > of the other packages built from systemd source. That is certainly reasonable too, although users avoiding systemd often express the intent of their desire as to avoid the entirety of the systemd ecosystem. Anyway, I think a lot of the project would like to get back to solving difficult problems via technical means, and this issue is one that can be solved that way. Best wishes, Mike [0] http://devuan.org _______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
