Differences between revisions 1 and 8 (spanning 7 versions)
Revision 1 as of 2016-12-18 21:36:37
Size: 678
Editor: GuillemJover
Comment: Add initial draft page to track potential source format design defects
Revision 8 as of 2017-01-03 10:59:55
Size: 1594
Comment: Add a tip for lamby and others
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
This page intends to track any possible design defect in the current source formats, so that they can be taken into account when and iff we decide to create a new source format. Some of these defects might be purely subjective based on different workflows or different views of how source packages or source distributions are to be handled. But just as well, we might list anything that might potentially put people off the current source formats. This page intends to track any possible design problem, limitation and defect in the current source formats, so that they can be taken into account as things with higher priority to fix or when and iff we decide to create a new source format. Some of these problems might be purely subjective based on different workflows or different views of how source packages or source distributions are to be handled. But just as well, we might list anything that might potentially put people off the current source formats.
Line 6: Line 6:

 * If you are keeping your source package in a VCS, and you don't use both `single-debian-patch` and `auto-commit`, your queue of quilt patches is a version control system inside a version control system. This is painful and time-consuming to manipulate. `gbp-pq(1)` is only slightly better than `quilt(1)`.

 * When just hacking around trying different approaches to a problem, its a little annoying to be forced into creating a "proper" patch in debian/patches (tip for people affected by this: don't rebuild the source package, just build the binary packages with dpkg-buildpackage -b).

== Issues with 3.0 (native) ==

 * People want the ability to use a non-native version for a native package, for some workflows, which hints at limitations in the tooling and similar instead of allowing this incongruency (expand). DebianBug:737634

This page intends to track any possible design problem, limitation and defect in the current source formats, so that they can be taken into account as things with higher priority to fix or when and iff we decide to create a new source format. Some of these problems might be purely subjective based on different workflows or different views of how source packages or source distributions are to be handled. But just as well, we might list anything that might potentially put people off the current source formats.

Issues with 3.0 (quilt)

  • VCS specific files get ignored by default, which can be a problem when converting back and forth from the source format to a VCS. https://lists.debian.org/debian-devel/2016/11/msg01012.html

  • If you are keeping your source package in a VCS, and you don't use both single-debian-patch and auto-commit, your queue of quilt patches is a version control system inside a version control system. This is painful and time-consuming to manipulate. gbp-pq(1) is only slightly better than quilt(1).

  • When just hacking around trying different approaches to a problem, its a little annoying to be forced into creating a "proper" patch in debian/patches (tip for people affected by this: don't rebuild the source package, just build the binary packages with dpkg-buildpackage -b).

Issues with 3.0 (native)

  • People want the ability to use a non-native version for a native package, for some workflows, which hints at limitations in the tooling and similar instead of allowing this incongruency (expand). 737634