Hi, Quoting Dima Kogan (2023-03-29 03:33:46) > The feature I'm asking for is that on a brand-new Debian install I think I > should be able to > > 1. apt install sbuild > > 2. create schroot for sbuild in whatever way > > 3. apt source package > > 4. cd package > > 5. sbuild > > 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. ;) > Omitting the "dh clean" (by relying on dpkg complaining) would be one way to > get this working. Yes. The downside would be, that this would mean you've this check that figures out whether you made any changes every time you run it. I'd argue that the most common way to run sbuild is *after* you've made some changes and not on a source package without modifications. If you want to build a source package without having modified it, then your above list of steps are wasting CPU cycles. Instead of unpacking the source package and then repacking it again, you could just: apt-get source --download-only package sbuild -d unstable package_*.dsc Or could could leave even the downloading of the .dsc to sbuild: sbuild -d unstable package Or instead of using apt to download and unpack, you could get the source package with debcheckout and build with gbp buildpackage and then use the --git-cleaner option to run something like "git clean -fdx && git reset --hard" before running sbuild. Cleaning like that also doesn't require any additional dependencies on the outside being installed. Would either of this solve your use-case? > Doing the "dh clean" inside the chroot after the Build-Depends have been > installed is another. No. Doing the dh clean on the inside does not solve your problem because before anything can be run inside the chroot, a .dsc has to be made availabe on the outside so that something can be copied into the chroot. To make the .dsc available on an unpackaged source package, sbuild runs the clean target first. I've explained this already in past mails. The input to sbuild is the .dsc. If you want to put anything in, it has to be made a .dsc first. If your input is an unpacked directory, it has to be made into a .dsc first. In that case, your directory needs to be cleaned before a .dsc can be made. > Maybe the above sequence shouldn't be expected to work, but that makes sbuild > less useful in my view. I'm still trying to figure out what you are trying to do. If you want to build a source package without modifications, don't unpack it but feed sbuild the .dsc directly. If you want to make changes to it, unpack it. But then, after you've made changes, the directory needs to be clean before it can be made into a .dsc again. > 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. > Probably others use sbuild in this way too? I guess I have no way of knowing. Me neither. I can find two other mails from people who didn't know that the input to sbuild is a .dsc (and thus the clean target needs to be run if you start from an unpacked source directory) in my inbox from the past eight years i've maintained sbuild. At this point I don't know anything that can be done from the sbuild side to act on this bug (hence the "wontfix" tag): - cleaning on the inside is pointless because it would not avoid having to clean on the outside - detecting changes would be pointless in most cases and a waste of CPU cycles because most people run sbuild *after* having made changes. If you don't want to change anything, then don't run from an unpacked source directory. Is there any reason to unpack a .dsc other than to make changes to it? Thanks! cheers, josch
signature.asc
Description: signature
