Bug#994388: dpkg currently warning about merged-usr systems
On Fri, Apr 08, 2022 at 09:36:21AM +0200, Wouter Verhelst wrote: > FWIW, I think the TC should punt this bug to a GR. > > The dpkg maintainer has chosen not to engage with the TC in #994388, and > now seems to be actively subverting a validly-made TC decision. > > I do believe it reasonable to assume the dpkg maintainer has a point if > he believes that the currently-chosen way of moving forward is harmful. > However, the right way for him to make that point would have been to > engage with the TC, the body constitutionally placed to resolve > conflicts of this manner, not ignoring them and then doing whatever he > wants when the decision inevitably doesn't go his way. > > I encourage the dpkg maintainer (Cc'd) to engage with the TC in this > matter. It is not yet too late; the TC can always roll back decisions it > made earlier if it believes, in light of new arguments, those decisions > to be wrong. However, if this does not happen, then that does not > inspire me with confidence that whatever the TC decides after weighing > all the arguments available to them, the dpkg maintainer will follow > that ruling. Given that, in case the dpkg maintainer chooses to remain > silent again, I believe the only way forward is for the TC to recommend > a GR under §4.2.1 of the consitution. This effectively means "TC cannot enforce its own decisions and everybody can ignore them". Also, who would enforce the GR results and how? Note that §2.1.1, at least in my opinion, forbids working against a TC decision, but doesn't say who would enforce that and how. -- WBR, wRAR signature.asc Description: PGP signature
Bug#932795: Ethics of FTBFS bug reporting
On Tue, Jul 23, 2019 at 01:54:10PM +0200, Santiago Vila wrote: > * Because this is a violation of a Policy "must" directive, I consider > the downgrade to be a tricky way to modify Debian Policy without > following the usual Policy decision-making procedure. Please also note that https://release.debian.org/bullseye/rc_policy.txt defines bug severities, not the Policy directly. For example, while the Policy says that a package in main "must not require or recommend a package outside of main", the RC policy says ""Recommends:" lines do not count". > Surely, the end user *must* be able to build the package as well, must > they not? I also guess it's not the only case when the buildd infra does things differently, the best known example is ignoring B-D alternatives. -- WBR, wRAR signature.asc Description: PGP signature
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
On Tue, Dec 05, 2017 at 06:48:45PM +0100, Julian Andres Klode wrote: > gpsd netbase | systemd-sysv > mandos systemd-sysv | lsb-base (>= 3.0-6) > micro-httpd openbsd-inetd | inet-superserver | micro-inetd | netcat-traditional | systemd-sysv > munin cron | cron-daemon | systemd-sysv -- WBR, wRAR signature.asc Description: PGP signature
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
On Tue, Dec 05, 2017 at 05:36:10PM +, Ian Jackson wrote: > One question I have is about this: "several packages now require just > systemd-sysv". Can someone refer to some examples, please ? Third random try from `reverse-depends systemd-sysv` yielded lava-server. -- WBR, wRAR signature.asc Description: PGP signature
