Re: Review of proposals
>>>>> "Simon" == Simon Richter <sjr@debian.org> writes:
Simon> Hi,
Simon> On Fri, Nov 29, 2019 at 11:44:55AM +0000, Ian Jackson wrote:
[regarding declarative facilities]
>> I have heard more than one person say that they are unhappy that
>> the current situation has been blocking specifically this kind of
>> progress.
Simon> In my opinion, that question is the core of the argument
Simon> we're having. Daemon startup is effectively solved on the
Simon> technical side, and the only question remaining there is
Simon> whether including an init script should remain mandatory or
Simon> not.
Simon> Non-init-related facilities are where I'd expect
Simon> incompatibilities to arise, and it is a bit sad that there is
Simon> only one amendment that effectively addresses this question
Simon> -- because if amendment D doesn't win, this GR provides
Simon> absolutely no guidance on what to do about packages that do
Simon> not work properly or at all if systemd is not PID 1.
I actually think all of the options provide guidance on this.
First of all, under all options currently on the table, programs like
cockpit that are designed for systemd and that have no way of working
without systemd are permitted. That is, under all five current options,
my reading is such programs are permitted and non-buggy.
If a program is not explicitly designed for systemd by its upstream,
under proposal E, it is RC buggy.
Under proposal A, it is buggy, NMUs are encouraged, but it is not
inherently RC buggy.
Under proposal C, the project has said that supporting multiple init
systems is not a priority, so fixing bugs that happen when systemd is
not pid 1 is not a priority.
I think you could still file a wishlist bug for that situation.
Proposal B is also clear:
>Packages may use any systemd facility at the
>package maintainer's discretion, provided that this is consistent with
>other Policy requirements and the normal expectation that packages
>shouldn't depend on experimental or unsupported (in Debian) features
>of other packages. Packages may include support for alternate init
>systems besides systemd and may include alternatives for any
>systemd-specific interfaces they use. Maintainers use their normal
>procedures for deciding which patches to include.
That is, the maintainer gets to decide what facilities they use and how
important it is for their package to work when systemd is not pid 1.
Proposal B involves a commitment to integrating technologies like
elogind into the project, but *not* a commitment to integrating these
technologies into leaf packages. That is, proposal B is about affirming
Debian as a place where we can experiment with technologies that enable
alternate init systems, while leaving which alternate init systems work
for a given package up to those maintainers.
Proposal B is not the option you want if you value sysvinit or runit as
a general purpose init system in Debian.
--Sam
Reply to: