Bug#981618: libdrm: reduce Build-Depends
On Tuesday, 7 November 2023 11:35:28 CET Diederik de Haas wrote: > I did add the removal of the 2 B-Ds in that MR, but as it doesn't include > all the items of this bug report, I won't close this bug with those > changes. FTR: https://salsa.debian.org/xorg-team/lib/libdrm/-/merge_requests/5 signature.asc Description: This is a digitally signed message part.
Bug#981618: libdrm: reduce Build-Depends
On Tuesday, 7 November 2023 14:06:23 CET Helmut Grohne wrote: > On Tue, Nov 07, 2023 at 11:35:28AM +0100, Diederik de Haas wrote: > > > I am not sure what you mean with heavy-handed here and why that would be > > > an issue. > > > > Not fully understanding it, it felt like "some tests may be problematic, > > let's disable all them" > > Do I understand correctly that this no longer is your understanding? Yep, it adds the option to not do the test and in that case you also don't need the build dependency. Thus it doesn't unconditionally disable (all) the test, but gives the option/flexibility to do so. Thinking about it some more, I actually use it myself a lot when building kernels. I pretty much always use the 'nodoc' profile, which saves ~1 GB of dependencies to install (IIRC, mostly due to texlive-latex-extra). Or use the 'cross' profile when cross-compiling a kernel. There's still a lot of magic (to me) involved and I don't fully/properly understand how it works (yet), but I do use it. > > While I'm now less clueless about this then before, I don't feel > > comfortable enough that I would be able to 'defend' the inclusion of the > > annotation, so I won't include that part in the MR I'm working > > on. > Fair enough. I can offer you two ways forward. You may add me as > reviewer, so I can do the defending part if it becomes necessary. The > correctness of a nocheck build profile can be technically validated. If > you locally perform a build with and without nocheck and both produce > the same artifacts (the reproducible bit-identical ense), then that's a > very strong clue that the dependency wasn't used for building (but maybe > used for testing). And since "nocheck" really means disabling all tests, > you're right in thus annotating the dependency. I actually have now build libdrm locally, but I usually let Salsa's CI do that for me. And I'm compiling it on my main PC and have yet to learn how to do it with tools like sbuild. It's on my TODO, but I'm not there yet. I also want to learn tools like diffoscope (I think R-B is amazing), but I don't understand (its output) one bit. One day I will, but that will not be in the near future. Did I miss option 2? Thanks again, Diederik signature.asc Description: This is a digitally signed message part.
Bug#981618: libdrm: reduce Build-Depends
On Tue, Nov 07, 2023 at 11:35:28AM +0100, Diederik de Haas wrote: > > I am not sure what you mean with heavy-handed here and why that would be > > an issue. > > Not fully understanding it, it felt like "some tests may be problematic, > let's > disable all them" Do I understand correctly that this no longer is your understanding? > While I'm now less clueless about this then before, I don't feel comfortable > enough that I would be able to 'defend' the inclusion of the > annotation, so I won't include that part in the MR I'm working on. Fair enough. I can offer you two ways forward. You may add me as reviewer, so I can do the defending part if it becomes necessary. The correctness of a nocheck build profile can be technically validated. If you locally perform a build with and without nocheck and both produce the same artifacts (the reproducible bit-identical ense), then that's a very strong clue that the dependency wasn't used for building (but maybe used for testing). And since "nocheck" really means disabling all tests, you're right in thus annotating the dependency. > I did add the removal of the 2 B-Ds in that MR, but as it doesn't include all > the items of this bug report, I won't close this bug with those changes. Fine. > Note that (currently?) the valgrand B-D is commented out/disabled in > debian/control, so together that may help with the (original) reason for > filing > this bug? Looking at the original reason always is a good idea. :) And yeah, the referenced bug #870176 has a cycle via valgrind. So while looking into libdrm was motivated by the presence of cycles. The approach was looking for low hanging fruit (i.e. relatively obviously unused dependencies) in packages relevant to cycles. So it's not about a particular dependency here. Helmut
Bug#981618: libdrm: reduce Build-Depends
On Monday, 6 November 2023 22:13:45 CET Helmut Grohne wrote: > On Mon, Nov 06, 2023 at 09:52:54PM +0100, Diederik de Haas wrote: > > > And libx11-dev is only used in some tests. > > > We can annotate libx11-dev . > > > > Is that still the case? > > I don't know. I filed the patch more than two years ago. A relatively That was one of the reasons I asked ;) > > Can you perhaps expand on why that annotation is appropriate (for my > > learning experience)? Policy 4.9.1 mentions "to not run any build-time > > test suite provided by the package" with the 'nocheck' tag, but that > > sounds a bit heavy- handed to me? > > I am not sure what you mean with heavy-handed here and why that would be > an issue. Not fully understanding it, it felt like "some tests may be problematic, let's disable all them" > The technical term for is "restriction formula" according to > man deb-src-control. It expresses that when the nocheck build profile is > enabled, the annotated dependency is disabled. The nocheck build profile > may be used together with the nocheck build option to disable running > build-time tests. Any such testing is not supposed to affect the output > artifacts of the package in case the build succeeds. The method I used > for validation here is performing such a nocheck build and comparing its > artifacts with a regular build using diffoscope. > > Note that none of the regular build daemons used for building packages > on release architectures ever enable this build profile. It is enabled > on some ports architectures and it is also enabled by default for cross > builds. Nevertheless, a failure to build with a nocheck profile is > considered release-critical since trixie, because the autoremover will > consider breaking annotated dependencies. Thanks so much for taking the time to explain it :-) While I'm now less clueless about this then before, I don't feel comfortable enough that I would be able to 'defend' the inclusion of the annotation, so I won't include that part in the MR I'm working on. I did add the removal of the 2 B-Ds in that MR, but as it doesn't include all the items of this bug report, I won't close this bug with those changes. Note that (currently?) the valgrand B-D is commented out/disabled in debian/control, so together that may help with the (original) reason for filing this bug? Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#981618: libdrm: reduce Build-Depends
On Mon, Nov 06, 2023 at 09:52:54PM +0100, Diederik de Haas wrote: > > And libx11-dev is only used in some tests. > > We can annotate libx11-dev . > > Is that still the case? I don't know. I filed the patch more than two years ago. A relatively > Can you perhaps expand on why that annotation is appropriate (for my learning > experience)? Policy 4.9.1 mentions "to not run any build-time test suite > provided by the package" with the 'nocheck' tag, but that sounds a bit heavy- > handed to me? The technical term for is "restriction formula" according to man deb-src-control. It expresses that when the nocheck build profile is enabled, the annotated dependency is disabled. The nocheck build profile may be used together with the nocheck build option to disable running build-time tests. Any such testing is not supposed to affect the output artifacts of the package in case the build succeeds. The method I used for validation here is performing such a nocheck build and comparing its artifacts with a regular build using diffoscope. I am not sure what you mean with heavy-handed here and why that would be an issue. Note that none of the regular build daemons used for building packages on release architectures ever enable this build profile. It is enabled on some ports architectures and it is also enabled by default for cross builds. Nevertheless, a failure to build with a nocheck profile is considered release-critical since trixie, because the autoremover will consider breaking annotated dependencies. Helmut
Bug#981618: libdrm: reduce Build-Depends
On Tue, 2 Feb 2021 07:34:35 +0100 Helmut Grohne wrote: > Source: libdrm > Version: 2.4.104-1 > Tags: patch > > libdrm no longer builds its documentation with xsltproc and ruses > restructred text now. It also no longer uses xutils-dev. I was able to confirm that those can be dropped. > And libx11-dev is only used in some tests. > We can annotate libx11-dev . Is that still the case? Can you perhaps expand on why that annotation is appropriate (for my learning experience)? Policy 4.9.1 mentions "to not run any build-time test suite provided by the package" with the 'nocheck' tag, but that sounds a bit heavy- handed to me? signature.asc Description: This is a digitally signed message part.
Bug#981618: libdrm: reduce Build-Depends
Source: libdrm Version: 2.4.104-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap libdrm participates in dependency loops (e.g. #870176) relevant to architecture bootstrap. As we noticed, this problem is hard, so I looked into easily droppable dependencies instead. Turns out valgrind is not one of them. On the bright side, libdrm no longer builds its documentation with xsltproc and ruses restructred text now. It also no longer uses xutils-dev. And libx11-dev is only used in some tests. We can drop the first two and annotate libx11-dev . Please consider applying the attached patch. Helmut diff --minimal -Nru libdrm-2.4.104/debian/changelog libdrm-2.4.104/debian/changelog --- libdrm-2.4.104/debian/changelog 2021-01-28 11:18:32.0 +0100 +++ libdrm-2.4.104/debian/changelog 2021-02-02 07:30:31.0 +0100 @@ -1,3 +1,12 @@ +libdrm (2.4.104-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Reduce Build-Depends: (Closes: #-1) ++ Drop unused xsltproc and xutils-dev. ++ Annotate libx11-dev . + + -- Helmut Grohne Tue, 02 Feb 2021 07:30:31 +0100 + libdrm (2.4.104-1) unstable; urgency=medium * New upstream release. diff --minimal -Nru libdrm-2.4.104/debian/control libdrm-2.4.104/debian/control --- libdrm-2.4.104/debian/control 2021-01-28 11:15:10.0 +0100 +++ libdrm-2.4.104/debian/control 2021-02-02 07:30:24.0 +0100 @@ -6,10 +6,8 @@ debhelper-compat (= 12), meson, quilt, - xsltproc, - libx11-dev, + libx11-dev , pkg-config, - xutils-dev (>= 1:7.6+2), libudev-dev [linux-any], libpciaccess-dev, python3-docutils,
