Re: Installing an Alternative Init?
Laurent Bigonville wrote:
Le Tue, 11 Nov 2014 07:42:33 -0500,
Tanstaafl <email@example.com> a écrit :
On 11/10/2014 6:18 PM, Michael Biebl <firstname.lastname@example.org> wrote:
Am 11.11.2014 um 00:14 schrieb Miles Fidelman:
Ok, then explain to me the procedure for running the installer in
such a way that systemd is never installed, thus avoiding any
potential problems that might result from later uninstallation all
the dependencies that systemd brings in with it.
Please be specific. What problems of of dependencies are you
Please stop bring up irrelevant questions and address the question
This does require you to at least understand and acknowledge the
difference between a *clean* install, and installing something one
way, then having to uninstall a primary piece and replace it with
The two are not the same, and no amount of you trying to act as if
they are will change the fact that they are not.
There are no functional differences between an installation with
sysvinit-core out of the box or an install where sysvinit-core is
installed later, this is a fact.
No, that's NOT a fact. At least it's not a tested and demonstrated fact
for complex configurations such as virtualized environments with
complicated file system wiring.
Based on previous experience, mostly with mail systems (install exim,
then replace with sendmail) and filesystems, it's very easy to find
oneself with all kinds of artifacts left behind by an install/replace
process; as well as finding one's way into lots of packages getting
installed/replaced and associated dependency hell.
I'm not particularly interested in testing how well install/replace
systemd and its dependencies works in our environment (both hypervisor
level or guest debootstrapped guest domain). Particularly during a
period where interfaces and dependencies are in flux as a result of
ongoing bug fixes.
I want to avoid the mess entirely with a clean install.
Actually, I don't really care about choosing it from the installer
command line - THAT's a nice-to-have, but (IMHO) a nice-to-have at least
as important as the choice of bootloaders provided during expert
install. What should be (IMHO) a RC bug is the fact that you can't
control this with a preseed command. Obviously those making the
Allowing the user to choose this at install time from the interface is
a "nice to have" feature (wishlist bug) not a RC bug like you were