[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Installing an Alternative Init?



Laurent Bigonville wrote:
Le Tue, 11 Nov 2014 07:42:33 -0500,
Tanstaafl <tanstaafl@libertytrek.org> a écrit :

On 11/10/2014 6:18 PM, Michael Biebl <biebl@debian.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
talking about?
Please stop bring up irrelevant questions and address the question
being asked.

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
something else.

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.

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
claiming earlier.


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 decisions disagree.

Miles Fidelman


Reply to: