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

Re: Old-timer installer, task-sysvinit?

Quoting Cyril Brulebois (2014-11-23 14:31:00)
> Jonas Smedegaard <dr@jones.dk> (2014-11-23):
>>> If you're unhappy about the initial systemd installation, that's too 
>>> bad, because we're not going to change debootstrap, especially not 
>>> at this late stage of the release cycle, to behave differently 
>>> depending on the target distribution. The current script covers all 
>>> suites from etch (etch, lenny, squeeze, wheey, jessie, and now 
>>> stretch), and it'd really be nice if that could stay the case.
>> I am unhappy about the need for messing non-declaratively with 
>> debian-installer in order to override default choice of init system.
>> It is nice that debian-installer provides hooks to do dangerous 
>> things, but I find it worrisome that changing init system involves 
>> use of that.
> I'm not sure why you're considering or calling preseeding “dangerous”.

Use of a root shell can turn a Debian system into a non-Debian system 
(by messing with the system in ways not following our defined rules).  
Blame is on the user for doing so.  Typos are unsupported.

Use of declarative hints should make it hard to do the same.  I would 
expect it to be treated as a bug if some hint wreaks havoc without at 
least popping up a strong warning first.  Blame is on Debian.  We 
support _using_ our system through the interfaces we provide - but some 
interfaces are less governed by us, hence more dangerous to use.

I consider it more dangerous to tell users to operate a root shell than 
have them type declarative hints.  Both gets processed as root, but the 
latter is far less likely for typos or misunderstandings to wreak havoc.

>>> There won't any more debconf, udeb, or whatever addition going to 
>>> happen. It means additional work (nobody has been doing that for a 
>>> whole release cycle), more maintenance, and… it's just too late.
>> Why do you say "for a whole release cycle"? Only late in the release 
>> cycle did init system become changeable without violating policy 
>> (removing core packages).
> Init systems have been a hot topic for most of the release cycle, with
> #727708 being finally referred to the tech-ctte in october 2013,
> meaning more than a year ago.

Until 4 months ago, choosing a non-default init system required typing 
"YES, I KNOW WHAT I AM DOING" or something similar, due to requiring 
removal of a essential package.

It is therefore no surprise to me that the idea of avoiding init from 
debootstrap comes up now rather than a year ago (for starters, that 
package didn't exist back then).

> It looks to me that people demanding so badly that debootstrap and/or 
> d-i accomodates for their init system of choice should have started 
> sending patches (to make init systems interchangeable or to support 
> “choice” in debootstrap/d-i/etc.) way ahead of the freeze.

Way ahead of the freeze we talked about changing default init.  I 
assumed that was similar to change of syslog daemon - i.e. if you want 
something else than the default (which is in Debian and stable and does 
not conflict with other things you also want) then you can have that 
through ordinary standard Debian ways.

Only few months ago did I realize that this default is different from 
other default packages, in that you cannot pick alternatives through 
standard package selection interfaces, but must use a free-form root 

Only now, today, do I realize that I am not even welcome to help work on 
creating workaround declarative interfaces - only option is "shut up, 
get in line" it seems.  I dearly hope I misunderstood you there.

Oh, and please, I do not demand anything here.  We are just talking :-)

Please cc me on replies,

 - Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature

Reply to: