Hi, Quoting Samuel Henrique (2024-11-30 23:26:03) > Hello everyone, just became aware of this bug due to > https://salsa.debian.org/debian/sbuild/-/merge_requests/71 > > I would like to explain why I would prefer sbuild to default to --no-clean and > ask if I'm missing something.
I am not fundamentally opposed to switching the default. But if it is switched, then there should be good reasons which should be explained in an entry to the NEWS file. What surprises me is that there is now an influx of people who have a problem with cleaning being the default. Before 0.87.1, sbuild just ignored whether the clean target is run on a system without the dependencies for that installed. One of the "resolutions" might also be to go back to this behaviour which I call buggy. But apparently now people are calling checking build dependencies before running dpkg-buildpackage a bug, so I guess my view of the world is skewed. > >> Other than that, can we run "dh clean" inside the chroot? > > What would that accomplish? > Running dh clean inside the chroot will remove the need to run it outside. No, it would not. The clean target inside the chroot is run *after* the source package is unpacked inside the chroot and that happens *after* the source package is packed up outside the chroot which in itself happens *after* the clean target is run on the outside. > > At the point where the .dsc is unpacked inside the chroot, it already is > > clean. You need a clean unpacked source directory, so that you can build a > > .dsc so that it can be copied into the chroot. So this cleaning has to > > happen on the outside. > > I don't know why it has to happen outside, why can't sbuild run dh clean even > when the input is a .dsc? The input to a run of sbuild is a dsc. If what you have is an unpacked source directory, then sbuild has to create a dsc first. To create a dsc you first want to run the clean target first. If you don't your source package might contain content that you don't want. This is why the clean target is run by default. > >> Today this doesn't always work, because sbuild wants to "dh clean" outside > >> the chroot. > > that is correct. But it could be said that this is still not a bug because > > you > > are using sbuild wrong. ;) > I agree that it's not a bug, but I think it would greatly improve the > usability of sbuild by making it simpler. > > Today, a person using sbuild needs to either A) Default to --no-clean-source, > B) Install build-dependencies whenever there are errors when building a > package, cluttering the host system. > > Both of these things require the person to also know about this detail. > > WIth --no-clean-source by default, there's no need to ever bother with it, and > that's what we recommend to mentees in the Debian Brasil community. The above is not correct. With --no-clean-source you might run into other problems (files you don't want are now part of your source). So there *is* a need to bother with it. There are also more than the options that you show above. There is at least also: C) don't default to --no-clean-source but tell "gbp buildpackage" to run sbuild with --no-clean-source because gbp will only run if the git tree is clean D) move build dependencies from Build-Depends to Build-Depends-Arch and Build-Depends-Indep E) pack up the source package into a dsc yourself and then call sbuild on the dsc > > - cleaning on the inside is pointless because it would not avoid having to > > clean on the outside > > If you clean it on the inside, you allow sbuild to have --no-clean-source by > default. Errrr... no. Why? > >> I can make --no-clean the default in my config, I suppose. > > Beware that this will lead to broken packages if you did make the wrong > > changes. That's why it's not the default. > > I guess this is where I'm likely missing something, considering the following > things: > 1) sbuild calls dh clean inside the chroot even when a .dsc is provided > 2) sbuild defaults to --no-clean-source > > What type of change can one make to a package which will lead to any type of > issue? $ apt-get source hello $ cd hello-2.10 $ dch -i $ touch debian/foobar $ dpkg-source -b . $ diffoscope ../hello_2.10-3.dsc ../hello_2.10-3.1.dsc [...] -rw-r--r-- 0 0 0 964 2022-12-26 15:30:00.000000 debian/control -rw-r--r-- 0 0 0 2264 2022-12-26 15:30:00.000000 debian/copyright +-rw-r--r-- 0 0 0 0 2024-11-30 22:46:47.000000 debian/foobar -rwxr-xr-x 0 0 0 141 2022-12-26 15:30:00.000000 debian/rules -rwxr-xr-x 0 0 0 798 2022-12-26 15:30:00.000000 debian/rules-old That. The hypothetical debian/foobar could be something created by running the full build or parts of the build locally. Those things are usually (if there is no bug) removed by the clean target. These days, our packages are mostly in git repos, so we can use "git clean -fdx" to even remove files that a buggy clean target would miss. Which is why it's pointless to let sbuild clean the source if you are working with git-buildpackage. But not everybody is. So if you switch the default then you break some user's setups. > As far as I know, running dh clean twice can't cause any issues. Changes > outside of the scope of dh_clean are not related to this issue as it won't > matter whether dh_clean is even run. > > I can't think of any scenario where this can lead to issues. I have shown one above. Do you need a more real-world and less hypothetical issue? Then I'll find a source package for you that exposes this. > I do acknowledge that this might lead to dh_clean being called twice, if the > user calls dh_clean when creating the dsc, but that doesn't seem to be an > issue. If really needed, sbuild could provide a parameter that lets the user > control whether dh clean is run inside (defaulting to true). I don't understand what this has to do with the clean target (it's not always dh clean) being run inside the chroot. That run of the clean target is completely irrelevant for this change. The clean target on the outside is necessary to produce a good dsc. That's what you will potentially upload to the archive. That's the thing that must not be buggy. > This way sbuild becomes much more "standalone", while still allowing users to > choose the other behavior. I would like to improve the situation but this is not it. Thanks! cheers, josch
signature.asc
Description: signature
