Hello Johannes,
On Sat, 30 Nov 2024 at 22:55, Johannes Schauer Marin Rodrigues
<[email protected]> wrote:
> 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.
I don't understand what "sbuild just ignored whether the clean target is run on
a system without the dependencies for that installed." exactly means, I always
had this issue with sbuild (even pre 0.87.1), I've been using --no-clean-source
by default for years now. I've been meaning to request this feature and I
always postponed, up until I noticed the discussion was already happening.
> 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.
I fully understand if at some point further you say it's a matter of personal
taste and you don't want to change (and I would be ok with that), but I feel
like we have not agreed on what specifically is being asked and the possible
solutions for this.
This characterization of the issue is not correct or fair, it's not what I'm
asking, so let me try to clarify it down below.
> 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
This would indeed solve the issue for users of gbp, but I think there's
potential to solve it for non-gbp users as well.
> 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
At this point it becomes easier to just install the build-dependencies in the
host machine, so I didn't consider these options.
> > > - 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?
Because there will be no difference whatsoever to the built package, but I now
understand your concern is what a crufty .dsc file, more below...
> > 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.
I believe I understand your concern now, so it would make sense to double check
that we're on the same page, please let me know if I'm missing something below.
* Considering a proposal to run the clean target inside the chroot instead of
outside by default.
* The risk of this issue is that the build-generated .dsc is created outside of
the chroot without "clean", and it would result in uploading a crufty .dsc to
the archive.
- This can only happen for files under "debian/", given dpkg-source will
error out if there are any upstream changes.
- This can only happen for files which are taken care of by the clean target,
as with cruft files not listed in the clean target will not be cleaned even
if we run it outside of the chroot.
* There's a "hidden contract" that ".dsc"s are always clean, and sbuild assumes
that's the case today by not running clean.
If this is not exactly your concern, feel free to ignore my proposal below and
let me know what I got wrong.
And just to avoid the (small) possibility that we are not in agreement on why I
would like this change, for clarity's sake:
I would like sbuild to build a package without requiring build-dependencies to
be installed in the host system. I don't think the current behavior is a bug,
this would be a usability improvement.
Now about proposals to address your concern, if we agreed on the definition of
the issue with the change:
Proposal 1) Bail-out on cruft:
* Default to --no-clean-source
* Add a parameter which lets users control whether "clean" is run inside the
chroot.
* Default to running "clean" inside the chroot.
* If there were any changes on debian/*, or the debian tarball differs from the
.dsc, bail out and tell the user there was cruft in the .dsc.
The failure scenario is so unlikely that this will be rare, so bailing out is
not problematic. This also enforces that ".dsc"s uploaded to the archive are
clean, as today sbuild will happily take that.
Proposal 2) Re-generate .dsc in chroot and use that instead:
* Default to --no-clean-source
* Add a parameter which lets users control whether the dsc file is re-generated
inside of the chroot.
* Default to re-generating the .dsc inside the chroot.
* If the "dsc" is re-generated inside the chroot, then run clean there.
* Generate a temp ".dsc" to serve as input to sbuild, then re-generate the
".dsc" inside the chroot.
* Use the re-generated .dsc as the final build artifact.
What do you think?
Thank you,
--
Samuel Henrique <samueloph>
