Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1102726 > unrolled thread

Bug#1007717: attempt to summarize current state of this bug

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1007717: attempt to summarize current state of this bug Matthew Vernon <matthew@debian.org> - 2022-05-10 18:10 +0200
    Bug#1007717: attempt to summarize current state of this bug Sam Hartman <hartmans@debian.org> - 2022-05-10 18:50 +0200
    Bug#1007717: attempt to summarize current state of this bug Lucas Nussbaum <lucas@debian.org> - 2022-05-11 11:10 +0200

#1102726 — Bug#1007717: attempt to summarize current state of this bug

Hi,

I thought it might be useful to try and summarize where we are with this 
bug, which hasn't see much recent activity (not least as there's a TC 
meeting later...).

* Questions asked of the TC

The Committee was invited to issue advice on a number of points:

I - continued use of 1.0 native format

1) declare that there is nothing with with a package with a native 
format but a non-native version number

2) request the dpkg maintainer relax the restriction of 3.0 native that 
prevents using that format with a non-native version number

3) declare that the MBF on the topic shouldn't have been filed against 
packages where the change is more complicated than simply change the 
source format

II - continued use of 1.0-with-diff

4) declare that there are circumstances where use of 1.0-with-diff is 
the best tradeoff between different considerations

5) declare that the MBF on this topic shouldn't have been filed against 
packages that are 1.0-with-diff (or at least not against all of them)

During the following discussion, TC has also been invited to come up 
with policy on native packages and Debian revisions.

* Package formats

The TC have been told that:

1.0-without-diff is in some circumstances better than 3.0 (native), 
because dpkg prohibits use of 3.0 native with a non-native version 
number; were that restriction relaxed, 3.0 (native) could replace 1.0-native

1.0-with-diff has advantages over 3.0 (quilt) particularly with 
git-based workflows, because in 3.0 (quilt) the diff is included inside 
the source tree

3.0 (quilt) with single-debian-patch can represent some changes to the 
source tree that 1.0-with-diff cannot

native format has the advantage over any quilt or diff format that it 
can represent some changes to a source tree that patch/diff cannot 
represent (e.g. changes to symlinks, which are changes you can make in git)

I don't believe any of these statements has been challenged.

* Discussion in the bug

Lucas (who filed the MBFs) has stated that they do not intend to make 
them RC, nor reopen ones that the maintainers close. This may well make 
3/5 relatively moot?

The issue of preferred form for modification has been raised (source 
package in general, quilt stack, or VCS repo); Sam states that there is 
consensus both that git workflows are best practice (especially where 
upstream uses git), and that natives packages are sometimes an 
appropriate tool to use. There is a wide range of git workflows, which 
the occasional NMUer can avoid caring about by use of dgit(7).

There was also discussion of whether 1.0 formats were "niche" - they 
represent 1.9% of packages in testing.

Russ argues that we should allow both native and non-native packages 
(defined by whether there is a separate upstream release from the Debian 
package) to use single-tarball source formats (and that the name 3.0 
(native) is a bit confusing here); Felix instead contends that "native" 
means instead that a package lacks a Debian patch, and we should stop 
defining native or otherwise in terms of version numbers. There was some 
further discussion of better terminology, but I don't think it went 
anywhere conclusive.

Updates / corrections welcome :)

HTH,

Matthew

[toc] | [next] | [standalone]

#1102729

[Multipart message — attachments visible in raw view] — view raw

>>>>> "Matthew" == Matthew Vernon <matthew@debian.org> writes:

    Matthew> Hi, I thought it might be useful to try and summarize where
    Matthew> we are with this bug, which hasn't see much recent activity
    Matthew> (not least as there's a TC meeting later...).

I read your summary and agree it is accurate.  Thank you.

[toc] | [prev] | [next] | [standalone]

#1102785

Hi,

On 10/05/22 at 16:57 +0100, Matthew Vernon wrote:
> 1.0-with-diff has advantages over 3.0 (quilt) particularly with git-based
> workflows, because in 3.0 (quilt) the diff is included inside the source
> tree

> The issue of preferred form for modification has been raised (source package
> in general, quilt stack, or VCS repo); Sam states that there is consensus
> both that git workflows are best practice (especially where upstream uses
> git), and that natives packages are sometimes an appropriate tool to use.
> There is a wide range of git workflows, which the occasional NMUer can avoid
> caring about by use of dgit(7).

I think that the two above paragraphs mix two different categories of
workflows:
- git-first workflows: packaging workflows that use git as the preferred
  form for modification, and use the source package format as an opaque
  output format
- git-using workflows: packaging workflows that use git for
  collaboration and tracability, but aim at producing a source package
  that is useful on its own (typically with a clean patch serie)

With this distinction made, I think that:
> 1.0-with-diff has advantages over 3.0 (quilt) particularly with git-based
> workflows, because in 3.0 (quilt) the diff is included inside the source
> tree
=> this really only applies to git-first workflows

> Sam states that there is consensus
> both that git workflows are best practice (especially where upstream uses
> git)

I think that:
- There is consensus that using a VCS, and Git in particular, for packaging
  is a best practice
- git-using workflows are a best practice (based on their usage by the
  vast majority of packages)

But I challenge that there is a consensus that git-first workflows are a
best practice. I think that they are a practice that is worth exploring
and experimenting on, but not yet widely adopted nor understood. But I
would be happy to be proven wrong (especially of based on facts).

Lucas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web