Hi!
On Wed, 2024-04-10 at 15:22:45 -0700, Vagrant Cascadian wrote:
> On 2024-04-09, Guillem Jover wrote:
> > I've now finished the change I had in that branch, which implements
> > support so that dpkg-buildpackage can be passed a .dsc or a source-dir,
> > and in the former will first extract it, and for both then it will
> > change directory to the source tree. If it got passed a .dsc then it
> > will instruct dpkg-genbuildinfo to include a ref to it.
> >
> > Which I think accomplishes the requested behavior in a safe way? I've
> > attached what I've got, which I'm planning on merging for 1.22.7. I'll
> > probably split that into two commits though before merging.
>
> Had a chance to take this for a test run, and it appears to work, though
> with a few surprises...
Ah, thanks for the testing, that was very helpful! :)
> dpkg-buildpackage -- hello_2.10-3.dsc
>
> Ends up regenerating the .dsc, as --build=any,all,source by default
> ... which may end up with a different .dsc checksum in the .buildinfo
> than .dsc that was passed on the commandline. Which makes some sense,
> but maybe would be better to error out? I would not expect to regenerate
> the .dsc if you're passing dpkg-buildpackage a .dsc!
Hmm, right I think I had documented that locally in the manual page,
but I can see how this can be surprising. I've for now switched the
code to not regenerate the .dsc when that is being passed, but the
problem is that I think the three options are potentially correct:
* regen: If you built the source on a stable/unstable system, then
you'd want to regenerate it on the target one (for unstable or a
backport or stable update), otherwise we might get compatibility
issues or missed updates. It is also what is being requested when
calling dpkg-buildpackage (as in "please build source and
binaries" :).
* no-regen: If we rebuild then we might end up with inconsistent
sources if these are tracked in different places, and if you pass
it the sources then it seems logical to expect them not to be
regenerated.
* error: This is the safe option of "both options are correct, let's
do none :D", of deferring the interface behavior.
Even though I changed it to no-regen for now, I'm thinking, though,
that the regen behavior is the more correct one.
> dpkg-buildpackage --build=any,all -- /path/to/hello_2.10-3.dsc
>
> Fails to find the .dsc file, as it appears to extract the sources to
> hello-2.10 and then expects to find ../hello_2.10-3.dsc
Ah, right, this is expected to be a filename not a pathname. (Placing
the source elsewhere is not currently feasible, see #657401; I mean I
guess dpkg-buildpackage could copy the source but…).
I've now added a check, although I'll be reworking it a bit before
merging, because it will emit confusing output if you specify
«./filename.dsc» as not being in the current directory. :)
> All that said ... this seemed to work for me:
>
> dpkg-buildpackage --build=any,all -- hello_2.10-3.dsc
>
> So yay, progress! Thanks!
Great, thanks!
> All of the above cases do not clean up the hello-2.10 extracted from the
> .dsc file, so re-running any of the above need to manually clean that or
> run from a clean directory or experience various failure modes with the
> existing hellp-2.10 directory.
I've also added an explicit check, and dpkg-buildpackage now will error
out if the directory already exists. I don't think removing a
pre-existing directory would be safe (at least w/o an explicit option
to do so). But perhaps, as you hinted, removing the source tree (for a
successful build) after finishing would indeed be an option, hmm.
> So a few little glitches, but overall this seems close to something we
> have really wanted for reproducible builds! And just for good measure,
> thanks!
I force-pushed the reworked code into:
https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/dpkg-buildpackage-dsc
Thanks,
Guillem
