Your message dated Mon, 24 Nov 2014 14:06:05 +0100
with message-id <20141124130605.gc19...@mraw.org>
and subject line Re: Bug#770812: tasksel: task-sysvinit to allow easy
installation of non-systemd systems
has caused the Debian Bug report #770812,
regarding tasksel: task-sysvinit to allow easy installation of non-systemd
systems
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
770812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770812
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tasksel
Version: 3.29
Severity: wishlist
Hello,
It has been argued that late changes to the debian installer should be
avoided, and the maintainers have clearly expressed that they do not want
to add another debconf question:
https://lists.debian.org/debian-boot/2014/11/msg00408.html
My proposal is not to forcibly have users answer this question and decide
on an init system upon install. But there seems to be a larger userbase
that does want to keep sysvinit (in fact, I have switched all my systems
to systemd; but I do have an interest to have the noise eventually stop).
Can maybe the "tasks" system help here?
Can we have a task-sysvinit which depends on sysvinit-core, and which
conflicts systemd-sysv, and does installing such a task achieve the
desired results at installation time?
IMHO, adding a task package is a minimally invasive change to the install
process, and given the many requests for a sysvinit install option, this
may well be acceptable to the release managers. It's just not entirely
clear to me whether this works (i.e. when tasks are considered during
the installation phase, and whether this allows overriding the package
providing "init"), and the procedure necessary to get such a change
accepted into tasksel, the installation media, and jessie.
(And yes, I'm aware of the preseeding option to pass
preseed/late_command="in-target apt-get install -y sysvinit-core"
to the installer. Essentially, I'm thinking of minimally invasive ways
to make this easier to access by end users - this is a pretty long
boot option to type, without the option of doing copy&paste when installing
a physical system...)
In the end, "Switch boot process to sysvinit" is a "task" that will end up
on the TODO list of many sysadmins (e.g. where because of some compatibility
or policy issue, they want to have all their servers on sysvinit)
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages tasksel depends on:
ii apt 1.0.9.3
ii debconf [debconf-2.0] 1.5.53
ii liblocale-gettext-perl 1.05-8+b1
ii perl-base 5.20.1-3
ii tasksel-data 3.29
tasksel recommends no packages.
tasksel suggests no packages.
-- debconf information excluded
--- End Message ---
--- Begin Message ---
Erich Schubert <er...@debian.org> (2014-11-24):
> Package: tasksel
> Version: 3.29
> Severity: wishlist
>
> Hello,
> It has been argued that late changes to the debian installer should be
> avoided, and the maintainers have clearly expressed that they do not want
> to add another debconf question:
> https://lists.debian.org/debian-boot/2014/11/msg00408.html
>
> My proposal is not to forcibly have users answer this question and decide
> on an init system upon install. But there seems to be a larger userbase
> that does want to keep sysvinit (in fact, I have switched all my systems
> to systemd; but I do have an interest to have the noise eventually stop).
>
> Can maybe the "tasks" system help here?
> Can we have a task-sysvinit which depends on sysvinit-core, and which
> conflicts systemd-sysv, and does installing such a task achieve the
> desired results at installation time?
>
> IMHO, adding a task package is a minimally invasive change to the install
> process, and given the many requests for a sysvinit install option, this
> may well be acceptable to the release managers. It's just not entirely
> clear to me whether this works (i.e. when tasks are considered during
> the installation phase, and whether this allows overriding the package
> providing "init"), and the procedure necessary to get such a change
> accepted into tasksel, the installation media, and jessie.
>
> (And yes, I'm aware of the preseeding option to pass
> preseed/late_command="in-target apt-get install -y sysvinit-core"
> to the installer. Essentially, I'm thinking of minimally invasive ways
> to make this easier to access by end users - this is a pretty long
> boot option to type, without the option of doing copy&paste when installing
> a physical system...)
>
> In the end, "Switch boot process to sysvinit" is a "task" that will end up
> on the TODO list of many sysadmins (e.g. where because of some compatibility
> or policy issue, they want to have all their servers on sysvinit)
Again, no.
Mraw,
KiBi.
signature.asc
Description: Digital signature
--- End Message ---
