> > Related to this, I have a question for Paul: > > > > We currently build Arch:all packages in amd64 autobuilders, and > > because of that, some people downgrade bugs about "Package foo which > > is Arch:all FTBFS on arm64". > > [...]
> Should all those cases be RC too in your book? Let's see... > Some source packages that build arch:all binaries (or even arch:any > binaries) lack Build-Depends on some architectures [1]. Yes. If you can't install the build-depends, you can't build the package the documented and normal way. It should eventually be RC. > Some arch:all > binaries can't be installed on architectures [2]. This is not RC, because the package can be easily excluded from Packages.gz so that it's not even available (I wonder if we do that already, btw). It would be only RC if it's used as a build-dependency on the same architecture, but this is already covered in the previous case. > Some arch:any packages > FTBFS on architectures where all their B-D are available. This is already RC now, and what we do in the cases where we can't fix it easily is to ask ftpmasters for the old binaries to be removed. In general, as far as a user of an architecture can't build a package which is available for such architecture in a stable release without doing "tricks" like jumping to another architecture, I believe it's a deviation from DFSG compliance. > If not, why special case arch:all? Maybe because it was just the first example which came to mind. > I think that having some package not build-able is unfortunately on > some architecture, but more or less in line with what we have to > accept on those other fronts. I think we don't really have to "accept" it, the same way we have decided not to "accept" unreproducible packages. > Also, do you have a proposal what maintainers should do in > those cases (assuming they can't find a solution to get it to build)? The same we do for reproducibility. We can make exceptions. > Add a fake B-D that can't be fullfilled on those architectures just > to document the fact? Would that fix your RC bug? I don't have a solution yet. Please note that it's not "my" RC bug. It's a deviation from the fundamental promise we make to users that they can rebuild all packages in stable. > What if later it starts to work (maybe > they were toolchain issues), we'd then never know. I think adding such a > fake B-D is worse than filing a bug report and leaving it open. (Not hiding > problems, but I can see how maintainers choose to spend their time > elsewhere. Pinging the porters is of course great). > > [1] https://qa.debian.org/dose/debcheck/src_testing_main/ > [2] https://qa.debian.org/dose/debcheck/testing_main/ > > > I think that's contrary to the DFSG and therefore wrong (if we require > > that package in stable must be buildable in stable, we should also > > require that packages in arm64 should be buildable in arm64). > > > See below on the DFSG, but otherwise I agree. (But I don't see a practical > way out here, so let's file the bugs but not at RC level). I don't see a practical way out either, other than actually fixing the bugs. I don't like the idea of "documenting" it with a new control field, because such field should not even exist to begin with. Reporting the bugs would be a good start, yes. Let's pray that nobody start saying they are "not bugs, just nice things to have". Some people still have what I call "Oracle mentality", by which it's good enough when "we" can build the packages in the buildds. > > However, this bug that you reported now means in practice that this > > package, which is Arch:all like many python packages, is actually > > required to be buildable on ppc64el. > > > No. Because it can mark the test to be skipped on ppc64el, we even have a > field for that: "Architecture: !ppc64el". Agreed. I was talking in a general sense. > > So, the question: How far are we from actually requiring Arch:all > > packages (not just by debian policy, but by release policy) to be > > buildable on all architectures on which they are supported, or at > > least on the same architectures where autopkgtests regressions are RC, > > like (if I remember well) arm64? > > > I hope I answered above, I think it's not the right tradeoff at this moment. Ok. > > I think that would be an important and necessary step towards DFSG > > compliance. > > I miss a point here I think. The DFSG doesn't say anything about building. Hmm, but when we say "packages in stable must build in stable", we usually say that it's to comply with DFSG. Packages can't be truly free if they can't be built, or if the procedure to build it is not well documented. Remember that the GPL considers the Makefiles and similar stuff to be an integral part of the source code, and by doing so it is implicitly assumed that they work out of the box. Those arch:all packages that are unbuildable on arm64 may be DFSG-free if we just look at their license, but there are not completely free in spirit. > All the rules about how to build packages came after the DFSG and are policy > territory, so more an ever advancing bar as we learn to do better. I think > you aim at something worthwhile, I just don't think it's time yet to have > the bar at that level. Ok. Thanks.
