On 23 October 2014 22:17, Uoti Urpala <uoti.urp...@pp1.inet.fi> wrote:
> The essential part was what you cut away:
>
>> > So you agree that there is no fundamental problem with packaging
>> > software that requires either systemd or uselessd? Does the GR still
>> > require "someone"(tm) to package uselessd for Debian before
>> > packaging
>> > that other (fundamentally OK even by your standards) software is
>> > allowed? To polish uselessd integration until it's actually a usable
>> > init system in Debian? I assume you are not volunteering for this
>> > work?
>
> In another mail, Ian said that his interpretation is that the init
> system would not only have to be packaged in Debian, but in testing and
> not RC buggy.
>
> So even GR proponents agree that software which works with either
> systemd or uselessd would be fine. Yet they want to FORBID packaging
> such software, unless someone packages and integrates uselessd for
> Debian. That's a large amount of work which would be mostly unrelated to
> the software running under those systems. And the proponents are not
> volunteering to do such work.
Software that works with either systemd or uselessd would be just
fine, exactly because the extra effort that it would take to make it
work with uselessd. That is because (as you show in the continuation
of your email) this extra work (like implementing the systemd-shim)
would also allow the same functionality to be used with any other init
system. And that is the whole reason for requiring that. One the
sotware is implemented with proper init-system-independance then all
init systems benefit from that.
>> I think that practical effect would be the same if we mandated
>> "support running with at least one non-default init system at PID 1"
>> or "support running with sysvinit at PID 1" or "support running with
>> any init systems in the archive at PID 1" from the point of view of
>> software being able to start with an alternative init system managing
>> the installation (not from the point of view of having init scripts
>> for all init systems).
>
> That's kind of backwards - the practical effect of the GR is pretty much
> to require that everything must implement sysv scripts,
No - you don't have to implement the startup scripts. But you must
make it possible for the startup scripts to be implemented by not
depending on availability of init-system-specific APIs (as in - have
checks and fallbacks for cases where they are not available).
> while there are
> init features that should not be considered to be/remain specific to
> systemd but sysvinit does not support. For example, any init system that
> Debian might want to switch to in the future will support systemd-style
> socket activation.
Actually - no. It is quite possible that next perfect init system
supports none of the systemd functions and even if it supports them,
it is likely that it will have a different API. Relying on a specific
API until it is an actual standart with a widespread implementation
across a majority of alternatives needlessly ties us down to what
systemd does currently. Even systemd itself might decide to change
some of its APIs at some point. Thus the actual functionality of
software should not depend on the existance of a particular API. It is
fine for socket activation feature not to work if that API is changed.
It is not ok for the software to refuse to work at all if that API is
changed.
--
Best regards,
Aigars Mahinovs mailto:aigar...@debian.org
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux (http://www.debian.org) |
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `' Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--------------------------------------------------------------#
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cabpywdua5yo01vboa5iemsg2br+om-yqpzo+abrjmy1rw0l...@mail.gmail.com
