On Thu, Jun 27, 2024 at 04:16:49AM -0500, Plasma (David Paul) wrote:
> On Tue, 25 Jun 2024 14:55:35 +0100
> Mark Hindley <mark@???> wrote:
>
> > Hi,
> >
> > Simon Richter highlighted on #devuan-dev that some of Devuan's orig
> > tarballs are different to Debian's. Whilst they are consistent within
> > Devuan, he was trying to bootstrap riscv64 on daedalus and ran into
> > file conflicts with bookworm in reprepro.
> >
> > Since my involvement in Devuan, we have discouraged the use of
> > pristine-tar (at the instigation of CenturionDan, IIRC) to avoid
> > binary blobs in git. Given the recent xz backdoor, I have been
> > satisfied that our position was justifiable. However, it is worth
> > reconsidering in the light of Simon's request.
> >
> > It seems to me that there are a few options:-
> >
> > 1) Continue as we are (internally consistent) and say that
> > frakendevubian setups are unsupported.
> >
> > 2) Use pristine-tar to ensure orig tarballs are binary equivalent
> > and tolerate the binary blobs in git.
> >
> > 3) Download orig tarballs from Debian as part of the build rather
> > than generating them afresh. Note that this will not work for
> > packages where we are ahead of Debian (slim, elogind) or Debian has
> > no package (eudev).
> >
> > Both 2) and 3) would only very gradually fix the situation as we
> > can't change existing orig tarballs in dak. So it is only an option
> > for ceres and only when a new upstream source appears.
> >
> > You may have other suggestions I haven't considered, if so do say!
>
> Here's my two cents.
>
> On several occasions, I've wanted to examine the delta between
> the Debian and Devuan versions of a package. As I have both repos in my
> sources.list (an unsupported configuration, but one I find useful and
> of which I am aware of the potential pitfalls), I would run something
> like
> ```
> apt source pkgname/ceres
> apt source pkgname/sid
> ```
> and then run debdiff, passing the two freshly downloaded .dsc files as
> arguments. Sometimes this works just fine. However, whenever the Debian
> and Devuan orig tarballs differ, debdiff errors out and I have to go in
> and manually edit the Files header of one of the dsc files to reference
> the other's orig tarball, updating the Checksums-* header and removing
> the now invalid digital signature on the dsc.
>
> After I've done all that, I can successfully run debdiff and get
> usable output. This works, but is tedious and annoying. This is my
> personal motivating factor for wanting Devuan to reuse Debian's orig
> tarballs whenever possible.
>
> I certainly appreciate the difficulty caused by not being able to
> switch affected packages to using Debian's orig tarball until Debian
> produces a new package release against a new upstream version with a
> new orig tarball. If all Devuan packages that currently use differing
> orig tarballs were to switch as able to reusing Debian orig tarballs,
> it would also have the nice benefit of being able to create local
> unified Debian+Devuan apt pools for archival purposes.
>
> I can also appreciate the desire to not bloat our git repositories;
> however, based on my reading of the pristine-tar(1) manpage it would
> seem to be virtually a non-issue in this case. "pristine-tar can
> regenerate a pristine upstream tarball using only a small binary delta
> file and a revision control checkout of the upstream branch." I'm in
> favor of tolerating "small binary delta file"s in our repos if it means
> debdiff works without manual intervention.

Do I understand? As I remember it, Debian uses pristine sources,
which contain the upstream source and a set of diffs to convert
the upstream source to the Debian version.

If we were to use pristine sources for the packages we modify,
would we just end up with a copy of the same upstream source
but a different set of diffs?

Or should we have the same upstream source and to sets of diffs,
to be applied one after the other?

And how could all this work with Devuan derivatives?

Amprolla probably does not need to be affected,
but could a modified amprolla help?

-- hendrik