[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1007717: Native source package format with non-native version

Hello Lucas,

Many thanks for providing this summary of your position.  Let me just
note a point of disagreement:

On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote:

> A point that I find important is the following: as a project, I think
> that we care about facilitating the review of changes we make to
> upstream source.

Certainly we do.

> I think that the preferred method (and widely accepted method) for
> that is currently to use the 3.0 (quilt) format with DEP-3-documented
> patches, on top of a tarball that contains the pristine upstream
> source.
> The git packaging workflows that generate source packages using either
> 1.0 native packages, or 1.0 non-native packages without patches, make it
> harder to identify and review those changes, as they require browsing
> the git repository, which sometimes is not properly documented using
> Vcs-*.

I don't think it's the preferred method.  I believe most of the project
sees git histories are the preferred tool for achieving the goal you

If we had only source packages for this purpose, then yes, 3.0 (quilt)
plus DEP-3 would be preferred.  But we have git, too, and indeed dgit.
Repositories for packages contain both upstream history and Debian
packaging history, and we have powerful git subcommands for extracting
information.  In many cases there is a good argument to be made that the
git history is part of the preferred form of modification.

Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply to: