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

Re: Installing an Alternative Init?

On Ma, 11 nov 14, 18:25:03, Miles Fidelman wrote:
> Andrei POPESCU wrote:
> >On Ma, 11 nov 14, 12:34:10, Miles Fidelman wrote:
> >>Laurent Bigonville wrote:
> >>>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.
> >Wasn't this about clean (minimal) installs? Where did the all the
> >complications come from?
> Clean as in install systemvinit from the beginning, not after systemd was
> first installed by default.

Let me rephrase: install from scratch.
> Where the complications come in is that, when talking about testing the
> assertion that there are no complications associated with an "unclean"
> install, I pointed out that testing in a real environment is different than
> on a basic machine.
> In my case, I'm worried about artifacts that might impact the stuff that
> I'll install immediately after the core system - like Xen, DRBD,
> cluster-glue, and then how an unclean install behaves inside a VM on top of
> that environment.

1. do a minimal install
2. replace systemd(-sysv) with sysvinit-core (e.g. via a late_command)
3. install your stuff

If you find any artifacts left by systemd after step 2. please report 
> >>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.
> >Do you have any concrete evidence for such issues in this concrete case?
> >Because I'm quite sure the developers would like to know about them.
> >After all, that's the purpose of piuparts.
> >
> >https://piuparts.debian.org/
> >https://piuparts.debian.org/sid/pass/systemd_215-5+b1.log
> >
> Sorry, but no.  I'm basing my decision on whether to invest time in in-depth
> testing on previous experience with what I consider to be analogous
> situations.

Just because some packages (you mentioned exim and sendmail) is (was?) 
buggy says absolutely nothing about other packages.

Kind regards,
Offtopic discussions among Debian users and developers:

Attachment: signature.asc
Description: Digital signature

Reply to: