El lun, 8 de sep 2014 a las 9:07 , Matthias Urlichs
<matth...@urlichs.de> escribió:
Hi,
Vincent Danjean:
If I recall correctly, when Debian switched the default MTA,
upgrades
did not change the already installed.
You cannot have an MTA without configuring it, and nobody even tried
to
implement auto-migration of the old default mailer's configuration to
the
new one. Also, we didn't switch to a different default mailer because
the
new one offered a heap of features and infrastructure which the other
lacked.
None of this applies to systemd.
I do not think that the reasons for switching are at all relevant.
These examples are unanimously pointing to defaults only being defaults
for new installation.
I think most people would expect that if XFCE remained the default
desktop for Jessie, then GNOME users should not be switched over
without even being asked. But this is not even a good example. What we
are doing here is switching **everyone**, even those who are using a
custom /sbin/init in their own repo or Upstart.
Furthermore, this switching is being done far more often than just at
upgrade time: everytime a user installs something that depends or
recommends libpam-systemd (indirectly or directly), he or she currently
have to double check that their init system is not being switched out
from under them. Install CUPS? Better know that you have to install
systemd-shim if you want to keep your init system...
The fact is that most "defaults" changes do not modify current user's
systems (MTA, syslog, desktop environment), and they definitely do not
do so without asking about it first (see /bin/dash).
Even if you do want to change it at upgrade time silently, the
systemd-sysv | systemd-shim bit does way more than that, and it does so
constantly and without any immediate guidance (i.e. install
systemd-shim).
A couple ways to make this better would be to add a message in
systemd-sysv saying that the system is being switched over (and that
installing systemd-shim may prevent this, at the cost of a less
complete/solid/whatever logind implementation), just switching the
dependencies around, or using virtual packages for logind dependencies
(since apt knows what is the best decision already).
Please consider the above prospective actions, and give feedback or
results.
Thank you for your time and effort,
--
Cameron Norman