]] Adrian Bunk > On Sun, Jan 19, 2014 at 11:00:01AM +0100, Tollef Fog Heen wrote: > > ]] Adrian Bunk > > > > > I already gave my hypothetical "udev gets a hard dependency on systemd > > > as init system" worst case. > > > To make the worst case even worse, assume a new upstream version of > > > systemd with this change gets released 2 weeks before the jessie freeze, > > > and gets uploaded into unstable immediately.[1] > > > > Then the systemd maintainer (i.e. me and the rest of the team) should be > > bopped on the head. > > > > I'd appreciate if your hypothetical scenarios aren't «let's assume that > > everyone are bonkers and do crazy stuff», since well, if they are, we > > need to fix that. The problem then isn't that they're uploading > > packages which are not appropriate for the archive, it's that they don't > > understand why that is a problem. > > What is bonkers and what is not is very subjective, and that's the > problem here.
No, it's not subjective. > If I was a systemd maintainer I would consider it a reasonable option to > rather upload a new version of systemd that adds such a dependency to > udev instead of shipping an ancient systemd in the next release. > > Or would you want to ship systemd 204 in jessie if that would > hypothetically be the only option for providing logind for > non-systemd in the jessie timeframe? That's not the point. The point is that it's not reasonable to break other people's packages in a significant and work-intensive manner two weeks before release, which is your scenario. There is no way that's ok. On the other hand, trying to formalise exactly how much you can inconvenience somebody how far in advance of the release is a futile exercise. Is requiring one other package to make a tiny change two years in advance of the freeze ok? If so, how about one year? One month? 20 days? etc. Don't regulate it explicitly but tell people that they have to behave reasonably towards their fellow developers. If people have no idea what that means, we already have a problem and need to fix that. If they disagree over the minutae, that's fine and we might need to decide exactly where the line goes in a few cases, but we can do that when the problem shows up, rather than try to antipacitate every case where it might go wrong. > > You can't regulate «don't be crazy», since if people want to, or don't > > understand what crazy means they will route around such a decision using > > technicalities. > > That's why in the case of Debian supporting multiple init systems (and > optionally additionally non-Linux ports) there has to be a strict policy > enforcing that this also stays supported. > > If you go bonkers tomorrow and add a dependency on systemd-sysv to udev, > will that be considered an RC bug that will prevent your package from > ever reaching testing until a udev without that dependency will be in > the archive? [1] I sure hope so. If nothing else because the package is uninstallable without manual override. It'd break unrelated packages. It'd probably break d-i. > If multiple init systems should be supported accordinng to the CTTE > decision, then the CTTE decision has to make it clear that "Yes" is > the answer to that question. Regulating the way you are advocating means you're moving the Overton window on what's considered acceptable or borderline acceptable and so I really don't think that's a good idea. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
