Norbert Preining <prein...@logic.at> writes: > This can happen on *any* server that has been booting happily since many > many years. Thus, systemd is *not* a drop-in replacement for now.
We should be realistic about this: it's not going to be, either, at least for a definition of drop-in replacement that involves no changes in behavior. Completely identical behavior is a very high bar that hasn't been met by any other transition of this type that we've made in the past. Dependency-based boot, the change to /bin/sh, and UUID-based mounting were all not drop-in replacements by that criteria. We *are* going to uncover latent bugs in packages, in system configurations, and in other things, and in some cases there will just be differences, which are not obviously bugs anywhere. We should do what we can to diagnose and fix or warn about those, but we also shouldn't be surprised that they exist (and should let users know via at least the release notes that this is a fairly significant change to the boot process). In this case, maybe we can add some transitional smarts to the same package that takes responsibility for upgrade prompting. What comes to mind is scanning /etc/fstab and look for filesystems that aren't set noauto or nofail but that aren't mounted and warn the user with debconf that behavior may change. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppji8mj9....@windlord.stanford.edu
