On 5 January 2014 00:07, Nikolaus Rath <nikol...@rath.org> wrote: > Uoti Urpala <uoti.urp...@pp1.inet.fi> writes: >> On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote: >>> Clint Adams <cl...@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: https://plus.google.com/106778988568562417860/posts/TFYPgcfmj9N I don't think gnome-calculator should gain Depends:gnome-shell in this case when it clearly has "functional dependency" =))) -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org