On 05/07/19 09:02, Simon McVittie wrote:
> On Fri, 05 Jul 2019 at 01:07:59 +1200, Daniel Reurich wrote:
>> Our packaging approach is more or less "unapplied" for 3.0(quilt)
>> packages, and (I think) pretty much universally using quilt and gbp -
>> only for changelog and buildpackage (because it does a nice pbuilder
>> based build process with all the checks for ensuring no stray patches to
>> the upstream source sneak in).
>
> Note that quilt and gbp-pq interoperate (they are both "unapplied" as far
> as this survey is concerned) so if some of your developers prefer gbp-pq,
> some prefer quilt, and some prefer dropping "git format-patch" output
> into debian/patches without any special tools, that isn't particularly
> problematic.>
> This matches what we do in the Debian derivatives I work on for my job,
> although we tend to use gbp-pq more than quilt.
>
I tried gbp-pq and found that unwieldy and in the end easier to just
learn and use quilt. But we generally leave it to the maintainer to use
what suits them - provided they don't push the patch-queue branches if
they use gbp-pq into our canonical group for packages[0]
>> We've universally stamped out using pristine tar ;-) and always use use
>> either upstream-branch or preferably upstream-tag.
>
> How do you get a .orig tarball that matches what your upstream released
> (if not repacking)? For packages you already have in your archive, how
> do you ensure that you get a .orig tarball that exactly matches the one
> already there?
In most cases these days we use the upstream branch that is usually also
there. I think I had one or 2 packages a couple of years back where I
pulled the source directly from upstream, but I think those packages
have all been dropped from devuan because we no longer need to re-build
those packages.
Incidentally we did have an issue where dpkg did change the compression
level between jessie and stretch releases where the sources didn't
change resulting in dak rejecting our source packages due to differing
checksums on the same source version. To fix that we just forced the
compression level in debian/gbp.conf so that the source archive always
produced the same checksum as what was there.
>
> There isn't enough information in the packaging and upstream branches
> of a typical git workflow to reconstitute a precisely matching .orig
> tarball: you have to either obtain .orig tarballs out-of-band, or use
> pristine-tar to encode the parts of the tarball that can't be reproduced
> from the git tree.
Really? I honestly hadn't noticed, but I will out of interest compare
between what's in our archives and yours.
>
> (This is less of a problem if you never package upstream versions of
> non-native packages that aren't already in Debian, because in that case
> you can obtain the .orig tarball out-of-band from the Debian archive, but
> for more general downstreams, having interesting packages at a strictly
> newer version than Debian, or packages that aren't in Debian at all, is
> sometimes necessary. I'd be somewhat surprised if Devuan never pulls in
> a newer upstream version, or an upstream package that isn't in Debian at
> all, for the packages that are only interesting in the non-systemd case,
> like elogind and the various non-systemd init systems.)
>
We use our dak only for packages we re-build, so we wouldn't notice if
the source checksum is different from whats in the debian archive for
packages we rebuild.
Our full public archive (deb.devuan.org/merged/) only provides the dists
part of the archive. This is generated by our tool amprolla3[1] and
generates the Packages and Sources with rewritten paths to each pool
file. We then use http redirects to redirect web requests to the
relevant pool in either deb.debian.org/debian/<suite> or
deb.devuan.org/devuan/<suite> depending on whether it's an untouched
debian package.
>> There was one outstanding issue in the "gitsrc" discussion that I had,
>> and that was clear handling of patches to the upstream source. The best
>> answer I can come up with that is to use a sub vendor namespace
>> "patches" and a branch per patch
>> ie "debian/patches/01-<brief-descriptor>"
>
> Can this approach cope with patches that textually depend on each other,
> like two commits that alter the same region of the same file, one after
> the other? (I can't see how it would, but perhaps I'm missing something.)
>
That would probably need something in the nature of the file
debian/patches/series (as per quilt) or using numeric or other prefix in
the branch name to enforce a clear sorting order for merging the patch
branches on top of the upstream branches.
> As far as I can tell, gitsrc was intended to be used with some
> patches-applied representation of a source package ("merging",
> "git-debrebase", "git-dpm", "git-debcherry" or "rebasing" in the
> table), similar to dgit's native "archive" representation, and unlike
> the patches-unapplied representation ("maintainer view" in dgit terms)
> that is used in your workflow (and mine).
I honestly couldn't comment on the intention of the proposers of gitsrc
but I like the idea of using git instead of quilt. However, I do see
the clear benefit of keeping patches on the upstream source properly
organised in the way quilt does. ;-)
--- References:
[0] https://git.devuan.org/devuan-packages
[1] https://git.devuan.org/devuan-infrastructure/amprolla3
--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722
Attachment:
signature.asc
Description: OpenPGP digital signature