[Pkg-sysvinit-devel] Bug#773895: Bug#773895: sysvinit: package to pin sysvinit during upgrades

[Michael Gilbert]

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