Hi Nicolas,

Sorry for taking so long to get back to you I've had some family issues to
deal with.

On Thu, Oct 19, 2023 at 12:42:18PM +0200, Nicolas Boulenguez wrote:
> > would it be possible to get dh-builtusing backported for bookworm? We
> > want to use dh-builtusing in ghdl (as you know ;), but I run my
> > package builds on bookworm, inside an sbuild chroot, so gbp breaks
> > when building the source package it's going to hand to the chroot.
> 
> Please first consider a simple solution that I have been using for
> years.
> 
> Dpkg-buildpackage --build=source (run by $tool) cleans the source tree
> before preparing the .dsc (that $tool then copies into the chroot).

Incidentally, I've done some light code review of dpkg-dev a while ago. I
was looking at how/when patches are applied/unapplied but the cleaning
logic is close by.

> The motivation for the cleaning was probably to prevent objects
> embedded into the .dsc, but

I think it might also be related to the automatic patch generation some
source formats support. From that perspective: if you don't clean up before
building the dsc the generated patch could contain build cruft. Of course
there's extend-diff-ignore to prevent this so I'm not entirely sure this
tracks.

> * dpkg-buildpackage now (source format 3.0) aborts when it detects a
>   file present in the source tree but missing or different in the
>   .orig tarball

I had this same throught "why can't we just disable pre-clean for 3.0
(quilt)" but that's forgetting about debian/. Build products end up there
so we need to clean those up or we could include build cruft in the dsc and
potentially change the behaviour of the build that way.

> The clean step may even be harmful.
>  * It requires build dependencies outside the chroot
>    (your issue with dh-builtusing).
>  * Even if these are installed, the versions and behaviour may differ.
>    (probable cause of your issue with dh-ada-library)

I suppose in theory this behavioural difference could reflect in the dsc
content. I don't think that's a really a huge problem, it's just another of
a number of reasons why a dsc freshly built from packaging git may differ
from whats in the archive.

I kind of see this (source) build diversity to be a good thing. It means
I'm going to encounter (and fix) issues users doing their own ghetto
backports (like I used to ;) are going to encounter.

Perhaps it would be worthwhile to setup some system (salsa CI?) to detect
this case tho.

I've been toying with the idea of setting up a Debian-wide system to nag
maintainers about out-of-date, inconsistent or plain broken packaging git
repos. This logic to diff the dsc against one built from unstable could be
part of that effort.

>  * The upstream clean process may execute surprising commands like
>      find . -name '*~' -delete
>      git reset --hard
>    or make applied debian/patches hard to revert.
>  * Various packages require incompatible Build-Dependencies.
>  * ...
> 
> You can disable the clean with
> # dpkg-buildpackage -nc
> # pdebuild --debbuildopts -nc
> or a similar gbp-buildpackage option.

I enabled this on my workstation by way of

    $ echo no-pre-clean > ~/.config/dpkg/buildpackage.conf

and after using it for a while I can't say I enjoy it or consider it
safe. It's wayyy too easy to forget to clean this way.

Even with git what may be missing is a hook in dpkg-buildpackage to abort
the (source) build when the worktree is unclean, but even then I'm not sure
gbp export-orig will apply debian/.gitignore if it exists, which could be
another pitfall.

> In case you want to keep a basic check of the clean target, the right
> place is a pbuilder script cleaning inside the chroot after the build,
> then reporting any difference between the source and the .dsc.
> The output is almost always either
>  * trivial to work-around in Debian
>    (echo '*.o' > debian/clean)
>    (fixing upstream may be another story)
>  * short enough to be easily ignored
>    (./configure),
>  * or a real issue.

I never really used pbuilder, I went straight to sbuild so I'm not sure
what this setup would look like, could you elaborate or show an example?

--Daniel

Attachment: signature.asc
Description: PGP signature

Reply via email to