Bug#727708: init system discussion status
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.
Best,
Nikolaus
--
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
»Time flies like an arrow, fruit flies like a Banana.«
Reply to: