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

Bug#727708: init system discussion status

On 5 January 2014 00:07, Nikolaus Rath <Nikolaus@rath.org> wrote:
> Uoti Urpala <uoti.urpala@pp1.inet.fi> writes:
>> On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
>>> Clint Adams <clint@debian.org> writes:
>>> > On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
>>> >> or alternatively
>>> >>
>>> >> 4. Packages may, however, depend on a specific init system (which may
>>> >>    not be the default init) for features that are not related to daemon
>>> >>    startup. Such packages will only be installable on systems running a
>>> >>    non-default init, but are permitted in the archive.
>>> >
>>> > As loath as I am to participate in this discussion, I have to ask
>>> > if your intent is to suddenly outlaw all the packages which depend
>>> > on runit.
>>> Are you asking me personally? No, that's not my intent. I merely think
>>> that a CTTE solution should spell out precisely to what extent a package
>>> must be compatible with the default init (i.e., if it must be fully
>>> working with the default init, or if it only has to provide daemon
>>> startup/supervision/shutdown for the default init). This is why I
>>> explicitly listed two conflicting, alternative wordings.
>> There are two different kinds of dependencies: dependencies expressed in
>> package metadata, and functional dependencies (as in whether the package
>> does anything useful with another init). Your earlier wording sounds
>> like it was talking about the former ("installable") and Ian's proposal
>> definitely was (explicitly mentioning package fields), but the "fully
>> working" you use now sounds like it's about the latter.
> I think that if a program functionally depends on another, but the
> package does not declare this dependency, then it's a bug. So in this
> context I consider functional dependencies and package dependencies to
> be the same.

Whilst generally a good position to hold, it would mean e.g. for
lightdm to have "Depends: logind | consolekit" even if
systemd-activation is used and sysv-init files are provided it
shouldn't have Depends: sysvinit-core | systemd-sysv, since no
packages should declare explicit dependency on an init-system, it's
expected to have one generally. Even for systemd-ui, i'd expect it to
show an error dialog "can't do much here".

Stepping away to a satirical case, here is how gtk+3.10 looks like
with Client Side Decorations and the new-style designed GtkHeaderBar
in XFCE:

I don't think gnome-calculator should gain Depends:gnome-shell in this
case when it clearly has "functional dependency" =)))



Reply to: