Hi, Quoting Aurélien COUDERC (2024-11-26 21:35:38) > a) Being a proponent of things that just-work™ I’d rule out a). If I, > building loads of packages every other day, cannot make up what needs to be > done to get it working how will newcomers or occasional contributors get > around that ? For me sbuild should work from the source package without > additional setup, as much as sensible.
that is precisely an arguement for d). If packaging is done in git and if the
git clone is clean, then what is the point of attempting to run the clean
target?
> b) Doable. Lot of work. Need to change our somewhat complex tooling [1] that
> generates and updates the build deps from upstream’s CMakeFiles. Also (maybe
> biased because we package mostly arch-dependent binaries) I would seem more
> logical to me to have a Build-Depends-Noarch stanza with the very few package
> needed so that the default Build-Depends contains the useful stuff.
Historically, we first had Build-{Depends,Conflicts}-Indep because people felt
it would be useful to single out the build dependencies that are needed for
building the architecture independent packages such that the arch:all buildds
do not have to install potentially insane amounts of dependencies to only
assemble a few arch:all packages. Then later, the sake of symmetry, the
Build-{Depends,Conflicts}-Arch fields were added to build arch:any packages.
See bug #629480 if you want to dive into the history of that. It's probably
much easier to change your tooling than to add a new field.
> c) Looks like a recipe for failure. Maybe only for relatively corner cases
> but it looks unexpected.
I agree. And that's why I think that the change is good and here to stay.
> d) If that ends up adding unexpected files to the build, clearly not a good
> option either. I don’t pretend that my build environments are clean enough
> that I can afford that. So maybe that’s a valid option but I’m not the one
> going to try and convince you. :)
My main argument against changing the default is, that it is just very easy to
change the default of this setting on your machine. If we were to change the
default, this would definitely warrant an entry in NEWS because people are
likely relying on this.
> You’re talking about fakeroot but is that the interesting part ?
No, fakeroot is not the interesting part here. Avoiding fakeroot is just
amongst the reasons why that change was performed. The other reason being that
before, we ran the clean target without checking that the dependencies to do so
were installed.
> It seems to me that sbuild previously ran the clean target inside the
> container having B-D installed, which is why it was working. I think that’s
> a property worth keeping regardless of the use of fakeroot.
This is not changing. Sbuild still runs the clean target inside the chroot with
all B-Ds installed.
The reason you notice the fact that sbuild runs the clean target on the outside
as well is, that now it also checks whether the dependencies required to run
the clean target are also installed. It did not do that before. But since
effectively all you need to run the clean target is debhelper and since you
probably have debhelper installed on the outside, you never noticed that you
did not have the build dependencies installed.
> So my preferred solution would be to mimic that behaviour and have :
> - the source tree is injected in the build container with the B-D installed,
> - the clean and build source stages happen there,
> - the container is cleaned / reverted to its initial state with only the B-D,
> - then it’s reused for the actual build.
Doing this is certainly possible but it would require a large refactoring of
how sbuild operates. Currently, the way how source packages are transported
into the chroot are via a dsc and the files it references. If you call sbuild
on an unpacked source tree, then the dsc has to be built first. To avoid
surprises, sbuild calls the clean target before running "dpkg-source -b ."
Changing the way source packages are transported into the chroot from dsc to
something else would be a very large effort. But of course, patches are
welcome. But this gets me to an option I forgot to list earlier:
e) do not run sbuild inside an unpacked source directory. Instead, create the
dsc in any way you like and then feed that dsc file as a positional
argument to sbuild. But this option is not so interesting I think because
if you create the dsc manually, then you have to verify that your unpacked
source is clean and if you have done that, then you can call sbuild with
--no-clean already and call it a day...
Thanks!
cheers, josch
signature.asc
Description: signature
