On Sun, Jan 01, 2023 at 01:53:31PM +0100, Santiago Vila wrote: > Adam Borowski escribió: > > nor any of people running archive rebuilds so far. > > FWIW: I am one of those people running archive rebuilds. > I rebuilt the entire bullseye distribution, and I'm trying > to make it FTBFS bug free, as mandated by both Debian Policy > and Release Policy.
Bullseye has been a non-moving target for two years, thus changing requirements packages there are expected to meet is grossly belated. There are cases where adding such a requirement is worth the effort (eg. new hardware, or a hitherto unknown type of bugs), but I don't see how something with no practical benefit qualifies. This doesn't mean I intend to stop your efforts for releases currently in development -- I've already fixed this very bug in unstable (even though I disagree with the premise). But doing this for stable... come on... On Sun, Jan 01, 2023 at 01:46:06PM +0100, Santiago Vila wrote: > El 1/1/23 a las 12:58, Adam Borowski escribió: > > Control: tags -1 +unreproducible moreinfo > > I don't think the unreproducible tag applies here. > > To reproduce, just try to build it in a chroot which does > not include tzdata. If debootstrap does not do that by default, > then it follows that you should not simply accept debootstrap's defaults. No tool in Bullseye produces such build chroots, and this is what matters here. There's no practical benefit of retroactively changing packages: neither security rebuilds nor packages built by the users themselves will lack tzdata (the former because of build tools, the latter because of how Policy 2.5 defines "required"). Thus: I argue this is not a bug, and that even if it actually is a bug, there are no practical benefits of fixing it in _stable_. We are free to redefine requirements for future releases, of course. > This is Policy 4.2: > > > If build-time dependencies are specified, it must be possible to build the > > package and produce working binaries on a system with only essential and > > build-essential packages installed and also those required to satisfy the > > build-time relationships > (including any implied relationships). > > So yes, this is undoubtedly a bug, because tzdata is not build-essential. It is. It is merely not included in the _informational_ list shipped by a metapackage by that name; it explicitly says: # This package is NOT the definition of what packages are # build-essential; the real definition is in the Debian Policy Manual. # This package contains merely an informational list, which is all # most people need. However, if this package and the manual disagree, # the manual is correct. And Policy 4.2 which you just quoted says: # (including any implied relationships) I'd say that the Policy declaring systems that lack Priority:required packages to be broken fulfills this clause. > I could agree that everything would be easier if debootstrap was fixed once > and forever: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060 > > If you can push for that bug to be fixed for bookworm, that would certainly > help. It seems that multiple debootstrap maintainers disagree -- and so do I. But, as I said before, I have no real objections to changing this for Bookworm. Making an upload to add the B-Dependency was less effort than arguing, and I've already one so, thus complying with whatever rule wins. > > I have nothing against adding such a B-Dependency in unstable: this is where > > new development is supposed to be done, preparing a new upload costs but a > > few mins of my time. On the other hand, updating stable requires extensive > > process and wastes the time of me, the Release Team, of people preparing the > > new point release announcement, of users testing and deploying the update. > > Of course fixing bugs takes a little bit of time, but it may also be argued > that > not fixing this kind of bugs produces weird effects which makes some people > to lose > some of their time (for example, me building the whole archive trying to keep > stable free > from any kind of FTBFS bugs). These bugs are caused only by your intentional change to build chroots you use. You can save that time by not doing that _active_ step for past releases. > If, despite having a trivial fix for the bug, you decide > not to fix it in stable and leave the fix for others, I will have less time > for other things > which I also want to fix. I know that some people will not agree, but I > believe fixing > FTBFS bugs in stable should be primarily a responsibility of the affected > maintainers. > Offloading the work to those particularly interested in stable does not scale > well. I'm all for fixing bugs in stable that: * are obviously bugs (rather than a point of debate) * have a practical effect (because our process for stable update is a lot of work) > I have still 87 FTBFS bugs to fix in stable. You are of course free to > not help me fixing yours. Per the Developers Reference, a mass bug filing of many bugs on the same topic is required to be discussed before filing. This is not usually done for obvious cases like FTBFSes on an _unmodified_ build infrastructure, but retroactively declaring 87 packages as RC-buggy in _stable_ certainly counts. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? ⠈⠳⣄⠀⠀⠀⠀
