XPost: linux.debian.devel.mentors

Hi,

In my experience many of the discussions about packaging workflows on
this list have many misconceptions, which in turn I think stems from
that our tools are a bit challenging to use, and the documentation is
somewhat lacking. Many tend to struggle to figure out how to do
something, and once they landed on a "local optimum" they don't want
to go through all the complexity to re-learn another way.

To combat the general complexity, I have contributed in the past year
to the Developer's Reference, to the Git-buildpackage manual and a
bunch of man pages in Debian. However, the official Debian
documentation goes a long way in trying *not* to be opinionated on
what is the recommended workflow, so I feel that my own blog is the
best place to write of what I would *choose* as the optimal workflow
for myself and what I teach to those I mentor who are just starting
their learning journey and can't cope with too many options, in
particular these two:

- https://optimizedbyotto.com/post/debian-packaging-from-git/
- https://optimizedbyotto.com/post/debian-source-package-git/

I have tried my best to make them relatively short, concrete and
illustrative with diagrams etc.

- Otto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.mentors

Hi Otto,

thanks for writing the two most comprehensive docs about packaging, git
and gbp I have read in the last years. I even tried writing some. Will
stop doing that now that your docs exist. Impressive work.

I have some comments though.

On Wed, May 28, 2025 at 06:36:00AM -0700, Otto Kekäläinen wrote:

I feel that my own blog is the
best place to write of what I would *choose* as the optimal workflow
for myself and what I teach to those I mentor who are just starting
their learning journey and can't cope with too many options,

I would suggest mentioning in your documents that they represent your
personal opinion and that people who want to delve into alternatives
could read the official docs here, here and here.

in
particular these two:

- https://optimizedbyotto.com/post/debian-packaging-from-git/

I would love this article (or a third one) explaining how to convert an
already existing package that was created using more conventional
workflows to a form that preserves at least the upstream git history
from the conversion point on. I guess that aligning the newly imported
upstream master branch and the existing upstream/latest branch needs
some serious git magic that is beyond what I can do.

We encourage our new maintainers to take over orphaned and/or existing
packages so they should learn how to do that properly.

I especially like the idea to work through MRs even in one's own
repository to allow for third-party reviews.

does it make sense to work in debian/latest and only last before pushing
for review create another branch next/debian/latest? I'd always
intuitively work in next/debian/latest directly.

Regarding Upstream MR/PRs, can I really directly push to a github
repository that I am not affiliated with to open a PR? Or did you omit
the fork/another remote part of the process here?

As far as I know, unfortunately gbp pq import/export need a clean
directory with all changes committed. The document claims that gbp pq import/export can be run "at any time".

My personal pet peeve is the difference between the source package and
the packaging git repository contents. Those two especially differ in
the state of patches: They're applied in the unpacked source package,
and not applied in the packed source package and in the git repository contents. That is for me a constant source of confusion and it would be
nice if your document would contain an explanation.

- https://optimizedbyotto.com/post/debian-source-package-git/

It hurts me a bit to read that Ubuntu is more famous than Debian. We're
doing the majority of the work.

Some of the command lines that repeat between the two documents vary. I
am sure that both ways work, but if the variation is not absolutely
needed, it shouldnt be there.

I have tried my best to make them relatively short, concrete and
illustrative with diagrams etc.

This is among the best documentation I have ever read in Debian. Thank
you very much, and I hope that you can make good use of my feedback.

Greetings
Marc

-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:

does it make sense to work in debian/latest and only last before pushing for review create another branch next/debian/latest? I'd always intuitively work in next/debian/latest directly.

I appreciate and applaus Otto's posts too, but can we please agree on debian/unstable, debian/experimental, debian/trixie, ... as our *default*? while still "allowing" debian/latest and and also debian/3.11 and
debian/3.12 and debian/foo and debian/bar?

I've come to think that dep-14 should recommend debian/* and more
specifically debian/unstable for uploads to unstable.

(And since this is a rather newer fallout from http://ppc64el.reproduce.debian.net/ I thought I would share.)


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

An app is just a website wrapped in enough IP so that the company that made
it can send you to prison if you dare to modify it so that it serves your interests rather than theirs.
Cory Doctorow, https://pluralistic.net/2025/02/26/ursula-franklin/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmg3iLMACgkQCRq4Vgaa qhxvjw//cz50ehQ21Luvssl5mWlaSRMgK3Xq3ggZyxmoo8WM28r3mKTl7TR61F/E riy89u2B0QGY5Er/Xfp2SE1FOVgp3zK3VYsDkNFEY+jpg1Rnb3RKQb7D2iP2SRfH WMqF3rg60PIOTS3YEsVkkPLXgW7JF5Fj3khEMcA6Avupchn4jT/M0TZnWcZ0oBgt XNRc/Bf0i13tCx3Sjh1Mgt2b4VRKo9heudTzbxjthCmlxJ7mtFZ+xxPSXS+QP6a4 3vjPu1rGdlJgOtfIk3LhWbU64RgclOPfi0t6rOkqpLXpIevUm2HydiaQDj5mATeR 4rkrRTBg4zhvtPzzTQT3lNuc/g+2g5h06ljelXvk0aoVCIykhc4M1JG94iIPYDip WgAKyim+IxPyUz54t2J5p7jt3hVfMBrIcSGf376s0vg1GCQamlbBaUIhG9X

Quoting Holger Levsen (2025-05-29 00:05:44)

On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:

does it make sense to work in debian/latest and only last before pushing for
review create another branch next/debian/latest? I'd always intuitively work
in next/debian/latest directly.

I appreciate and applaus Otto's posts too, but can we please agree on debian/unstable, debian/experimental, debian/trixie, ... as our *default*? while still "allowing" debian/latest and and also debian/3.11 and
debian/3.12 and debian/foo and debian/bar?

I've come to think that dep-14 should recommend debian/* and more specifically debian/unstable for uploads to unstable.

(And since this is a rather newer fallout from http://ppc64el.reproduce.debian.net/ I thought I would share.)

https://dep-team.pages.debian.net/deps/dep14/ currently says...

Packages uploaded to the current development release should be
prepared in either a <vendor>/latest or <vendor>/<suite> branch

If you suggest that using "debian/latest" should *not* be done by
default, then it seems that requires reverting changes to DEP-14.

Personally, I don't see a problem in finalizing DEP-14 with its current wording, but I might miss something (more generally relevant than "let's
just all use git-buildpackage" which I don't think is what you are
saying here).

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============↕26836500003773219=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJoN4xZCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmfqdE+ZQhJUFQ5nyR0QYXQNMnY55gu4Xl0gFUPHpGJ+ xRYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAABVmw//TJ4jQ9XqaxFyMWpnTqVHHd8f acbgbttLuOelIimN/d37zw8T5P8FbEW/sZa7Ksy+81joADfuWwi+pwMPnTbh6ra9 KzQ9h+4KZVlegdGQWTkUqFx4zXmI5bDFugldEw06ZWWXljHqPW1q5dd+Lk11/wij AiQDpSC7e4kQCKrwsVtq1LpgTzwk2aaNX29xPzLCJzSxWc+YW8jFgkSZAnzlPu2p SJAXrnDhS473DyWud6NpwIAwid8cD2IKHBmReBKEnNmL1VkNUNm7Sxu2hDS5QR7a rVh1dkiHkyyazMYq4ZG5BCnJ85YCjcP5QK+T/rWq56/LRYGHiKKID3+mdJF+1UWh wkDcy1qh/rD6BDpZ+V+hBLA7PLCSja4UINctVOkZ

On Wed, May 28, 2025 at 10:05:44PM +0000, Holger Levsen wrote:

I appreciate and applaus Otto's posts too, but can we please agree on debian/unstable, debian/experimental, debian/trixie, ... as our *default*? while still "allowing" debian/latest and and also debian/3.11 and
debian/3.12 and debian/foo and debian/bar?

I've come to think that dep-14 should recommend debian/* and more specifically debian/unstable for uploads to unstable.

(And since this is a rather newer fallout from http://ppc64el.reproduce.debian.net/ I thought I would share.)

rather hillarious copy'n'paste error, instead of ppc64el... I ment https://wiki.debian.org/DebianEvents/de/2025/MountainCamp

(signature choosen semi-randomly only :)


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

„Never argue with an idiot. They will drag you down to their level and beat
you with experience.“ (Mark Twain)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmg3lckACgkQCRq4Vgaa qhz31Q//XuH13xJCFW3aarfzxgiasPBwAdyHXUrwtVV89LJ4hdSIAwl08IHzdvfj /mW557BtunKmyZ/3c3eT6APudSzplu5dTOgVOIPJGdVJZVArQ21HpJvv3RIagaDm EAmp7lX+6vIZIi8mNJYEHnVQFyOjb6og4Xw3tW9VgXv0Y7nVB7lRm6p9LROJh3js dI6wMT5z3HaSXEUtsBm9hTi9J3RppdZ/3BGtVnTE8iL/0Xgubz1h2lQqsHkK++x7 ExLbID0buIfV2nAUdOFZMXTAHE/W9GbDVHIBGnoCgNrSxc6WFpr9OgTwYlldUg3Z jORvHNKqz98SFGUARXX6ty5LPhQSCAlLqYhIyi4FQyU2S6C0OWIirck2EO9M7ojp eaJt1sd0Ena7Mkoe3PVGpRN9NizlNYZAue/2umlJgPxFhJsUYlHMVtDAY/N/zd86 KSZaIZXCBL4TM+7OQO7489qg4pvMgtzuSu6C+HTeJKKown80hFyczZRiO1OXelCj 85h3y98id4Z2XnrLSxxUF3pMWoksgmiDH8kBFH1+/NiaVYbYJaW29oEFrD5zkh

On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:

If you suggest that using "debian/latest" should *not* be done by
default, then it seems that requires reverting changes to DEP-14.

yes. dep14 currently says "that uploads to unstable and experimental should
be prepared either in the debian/latest branch or respectively in the debian/unstable and debian/experimental branches."

I think it should (instead) recommend debian/unstable (for uploads to unstable) (and in very brief) allow any debian/* branch layout & probably specifically name certain common ones.

Personally, I don't see a problem in finalizing DEP-14 with its current wording, but I might miss something (more generally relevant than "let's
just all use git-buildpackage" which I don't think is what you are
saying here).

my biggest problem with dep14 is that it doesnt recommend *one* layout. my biggest problem with how I see that interpreted is that I think debian/unstable is much better than debian/latest *as a default recommendation*.

because IMO debian/latest is rather *not* helpful when uploads to experimental are involved. and because debian/unstable is rather very clear what this
branch is about.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Segregation was legal. Slavery was legal. Don't use legality as a guide to morality.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmg3mDMACgkQCRq4Vgaa qhwtXg//fQgg2FTsk9f2VvswT0ZZ5nUTioTHA9l2a5NQv5X0AJ9NS17a/trlpt2j ioK64Ebk+qyBwOFoH2WUgs9tT1CXJGLljDCw/fHhET3/tF/W/YZtHwy5tOlFT516 zvr6/JB4AjU+bzfy3e7PyldtsHcvBPHtq0/rDJEXN8ZS13j3vmH6Tt5XTti3bAgr vBZbXwmnxDS054w6pBFj2TmOBIk+FkbxDTH/NS3WQIxr1p2+M6Bkjogd6pBbLyve 49uSxdHL+MPoPMwVuqbUl9sxRXT46cMGiP00SfIiWMiWAXxdqUMwmsrafUy7W8Z6 t4xwJnQhsMcJ0o5f3Ij6nSzJPMt70XxHJxKWHds3l9yi7iI+ULM0XEvysteo155Y fbKv4EzHqZCFsqOKvQC4SZMPFDcWJJfyKfJ/4FL84zBJlQ9nChqwECVaqSD1teQW spf9rPwHStWx1Nfzo/NctgJFzNjpcKmS5H/4WN0FQKKL4VMH987BS7lRDklFsVXQ irwOJrL4Wnlg9ib3RliewGT8MLZX+Ss02ms35IIyhdtz9pehaoB8X6+NRo40oYxc SNcUrLKJlhTij+gXJdTQZzEbWHs

XPost: linux.debian.devel.mentors

Hi,

On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:

thanks for writing the two most comprehensive docs about packaging, git and gbp I have read in the last years.

Impressive work.

+1 !

On Wed, May 28, 2025 at 06:36:00AM -0700, Otto KekΣlΣinen wrote:

in
particular these two:

- https://optimizedbyotto.com/post/debian-packaging-from-git/

<snip>

My personal pet peeve is the difference between the source package and the packaging git repository contents. Those two especially differ in the state of patches: They're applied in the unpacked source package, and not applied in the packed source package and in the git repository contents. That is for me a constant source of confusion and it would be nice if your document
would contain an explanation.

<snip>

Isn't this what dgit is supposed to solve?

Bye,

Joost

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Wed, May 28, 2025 at 11:11:47PM +0000, Holger Levsen wrote:

my biggest problem with dep14 is that it doesnt recommend *one* layout. my >biggest problem with how I see that interpreted is that I think debian/unstable
is much better than debian/latest *as a default recommendation*.

because IMO debian/latest is rather *not* helpful when uploads to experimental are involved. and because debian/unstable is rather very clear what this
branch is about.

Would I then branch from debian/unstable to debian/experimental and then
later merge back to unstable for an unstable upload.

I think for a package who is usually maintained in unstable and only occasionally has an experimental version (for example during freezes or
when especially large changes are tested [for example adduser's new
logging code]), debian/latest is the correct way, while packages that
almost constantly have an experimental version (for example when the
maintainer is really good at uploading upstream betas) should have debian/unstable and debian/experimental.

For this, my uneducated guess is that there is no "right" way that fits
all. I might be convinced otherwise, but I don't have anything to say
anyway.

Greetings
Marc

-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.mentors

Hi,

On Thu, May 29, 2025 at 05:26:31AM +0200, Joost van Baal-Ilić wrote:

On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
<snip>

My personal pet peeve is the difference between the source package and the >> packaging git repository contents. Those two especially differ in the state >> of patches: They're applied in the unpacked source package, and not applied >> in the packed source package and in the git repository contents. That is for >> me a constant source of confusion and it would be nice if your document
would contain an explanation.

<snip>

Isn't this what dgit is supposed to solve?

Even with dgit you still have a source package, and the dgit docs are
full of distinction between patches-applied and patches-unapplied. dgit
is one of the reasons why you NEED to know that.

Greetings
Marc

-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, May 29, 2025 at 09:21:13AM +0200, Jonas Smedegaard wrote:

Perhaps, to ease the burden of those of us maintaining many packages,
we could instead have this more complex rule:

The default debian branch is the first available of these, in order:
1. debian/latest
2. debian/unstable
3. debian/experimental

Please note that Otto's document is HIS personal preference and that he deliberately chose to offer HIS way without alternatives. I think he is entitled to. So, this discussion is actually about DEP-something (I hate
those numbers, I always mix them up) changing, right?

Greetings
Marc

-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Xiyue Deng (2025-05-29 06:15:30)

Hi Holger,

Holger Levsen <holger@layer-acht.org> writes:

On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:

If you suggest that using "debian/latest" should *not* be done by
default, then it seems that requires reverting changes to DEP-14.

yes. dep14 currently says "that uploads to unstable and experimental should
be prepared either in the debian/latest branch or respectively in the debian/unstable and debian/experimental branches."

I think it should (instead) recommend debian/unstable (for uploads to unstable)
(and in very brief) allow any debian/* branch layout & probably specifically
name certain common ones.

Personally, I don't see a problem in finalizing DEP-14 with its current
wording, but I might miss something (more generally relevant than "let's >> just all use git-buildpackage" which I don't think is what you are
saying here).

my biggest problem with dep14 is that it doesnt recommend *one* layout. my biggest problem with how I see that interpreted is that I think debian/unstable
is much better than debian/latest *as a default recommendation*.

because IMO debian/latest is rather *not* helpful when uploads to experimental are involved. and because debian/unstable is rather very clear what this
branch is about.

I am not yet a DD, but I maintain packages as a DM. Just want to
provide a perspective from a "debian/latest" user, as I found using "debian/latest" easier personally.

When I need to experiment something on experimental and intend to upload
to unstable as soon as the experiment succeeded, using "debian/latest" provides a simple linear git timeline. If I were to use
"debian/unstable", I would need to sync "debian/experimental" with "debian/unstable", do experiment there, upload; and once done, I would
need merge "debian/unstable" with "debian/experimental"; and after
future upload to unstable, "debian/experimental" becomes stale again and requires another merge in the future. As I don't intend to let the experimental version stay long, I think using two different branches for unstable and experimental unnecessarily complicates the process.

Just my two cents.

Thanks for describing that usage pattern well, Xiyue Deng.

I find it sensible begin packaging targeted experimental, and move the
package to unstable only when stable (yes, that is one common confusion:
the notion of "stable" versus "unstable" is descriptive not for the
package itself but for the *integration* of packages, which also
emphasizes targeting experimental initially: At first, there is zero integration which commonly equates to zero integration stability).

...but yes, then later on I use experimental branch for either of two
patterns: Either an experiment not expected to lead anywhere in itself
(but possibly reused e.g. through cherry-picking into another branch),
or an experiment expected to stabilize and get merged in another branch.

If we really want to etch a default branch into the DEP-14 spec, and it
should be mainly targeted newcomers to Debian, then I think the default
should be "debian/experimental" to limit the amount of information
needed to declare for creating a package from scratch.

Perhaps, to ease the burden of those of us maintaining many packages,
we could instead have this more complex rule:

The default debian branch is the first available of these, in order:
1. debian/latest
2. debian/unstable
3. debian/experimental

That would cover both those who prefer to explicitly name if their
latest mainline work is currently targeted the Debian unstable suite or
not, and those who want explicit branches only when need for distinction
arise.

Please also note, that "need for distinction" may not involve unstable/experimental suites: I maintain packages with zero distinction
between unstable and experimental but a need to distinguish stable or
oldstable updates.

- Jonas

P.S.

Tools taking legacy git branch naming into account could append this:

4. debian

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============#18753871266823586=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJoOArkCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmczmZikNruWXwIXvr26P5QawBZ/qzDd7AjZeaXDonoU fRYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAABPgQ//TgzrVEIIDx7WL0JEDbxWH6m+ FjpExlq2GnE6sBj8IjU7Gjr02Z49tn8sMITJEdEwnydO7rQSuQDoee7Wu5OGS0Bh xXVX5LrgfZpcDq8sw+Ha7mglw4d+b+Bge0GGqBNglnM0Rxa9M9FfdJrPKuXP3thD /MIJz6X/goDxaj3DlSvtWklsZzLg0ZNN/H3osrsE77Lrb2a5d2maKIMITBwNdZ9A 7re86kuNkLT1kq3RDeM28Vt3x53MBw77AKND5buk7HEaRWy4UAGAotzrrIihYhvG Af24wDgGgI9aH6QH/I/db0uxpYFCNrKpJUkkGD7t38ikTmZSic+pwVZHLsFBheIZ AjWftsJP8qGsfxgnys75mYgviDyO7DXd0AlDa79V

Quoting Marc Haber (2025-05-29 09:57:07)

On Thu, May 29, 2025 at 09:21:13AM +0200, Jonas Smedegaard wrote:

Perhaps, to ease the burden of those of us maintaining many packages,
we could instead have this more complex rule:

The default debian branch is the first available of these, in order:
1. debian/latest
2. debian/unstable
3. debian/experimental

Please note that Otto's document is HIS personal preference and that he deliberately chose to offer HIS way without alternatives. I think he is entitled to. So, this discussion is actually about DEP-something (I hate those numbers, I always mix them up) changing, right?

Whoops, you are right.

Sorry, Otto, for hijacking the thread about your opinionated guidelines.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============E42958907248305956=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJoOBUpCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmdvAafgp1stR7JMqpBvW5aRYTaVKK0hgt9XhS36oP/m 7RYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAACB4xAAmFARpqd6tDvvDcKL+MawW24W b9/tTJG77DU8SPAzK0uHRAQPyuibFrqSP3NQ8vvHDnC5fjT5uzkje/9VrrkW6wqK MvNYCuprh3GD9n6c74teg+Rf6GqL82XAyvncjncq16/L7k2HF1qyWuRhQF4sXH1G /cAKjGx2laHS2wdKP7MKwFCk+pLtXG3FImptdOeOBEhXg2QuF0V0xYRAdSINkY/c 10gutCFL1T+bUQkhUJvbBeBY2uVakmD9cNITPB1kPcLTj6wxDfoz7omsbxdbBxcM jWFi68M5saR1dMRVCqdYhzHANUfpy8CF/H2c8PhuyuF0SPx55An6oBEY1A1x37lv bTvBBLrLZZk0zuROHvMqZlbP2BusSjKYRQy0XJcY

XPost: linux.debian.devel.mentors

Hi,

On Thu, May 29, 2025 at 09:39:01AM +0200, Marc Haber wrote:

On Thu, May 29, 2025 at 05:26:31AM +0200, Joost van Baal-Ilić wrote:

On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
<snip>

My personal pet peeve is the difference between the source package and the
packaging git repository contents. Those two especially differ in the state
of patches: They're applied in the unpacked source package, and not applied
in the packed source package and in the git repository contents. That is for
me a constant source of confusion and it would be nice if your document would contain an explanation.

<snip>

Isn't this what dgit is supposed to solve?

Even with dgit you still have a source package, and the dgit docs are full
of distinction between patches-applied and patches-unapplied. dgit is one of the reasons why you NEED to know that.

A, indeed. Otoh the dgit-people feel a source package should be treated as an intermediate build artifact; not something to be consumed by humans.

The problem dgit solves (afaiu) is: one can be sure the git thing one gets
from dgit is of the expected format wrt the patches.

Bye,

Joost

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.mentors

Hello,

On Thu 29 May 2025 at 05:26am +02, Joost van Baal-Ili─ç wrote:

Isn't this what dgit is supposed to solve?

dgit solves this for people wanting to make local changes and NMUs, yes.

For maintainers, if you want to use patches-applied dgit will be happy
with it but you'll probably want to use git-debrebase or git-dpm or single-debian-patch in addition to dgit.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmg4KNEZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQKU9D/93vEB/j5xTpTwWPT3PxSrn jFv5BT+6wS9peMh7uEjowSr1TIeV/OMIKbZRuWQs7di2lalxj7Buskdc5i0GnURG 3iTlPCTp/K8MNEYU974RbYfgDz0WTpFM50mFnTdmfXcb/ByQl8GhoSOg1x3AsXDR v2GGkbC267BO+TdcpyktI3eJxjP1NzE7LTS6F/wKVFc9cu11utS39F3WUHxlxQBB rFtNlRQiCexZK4QUVXaH00L8sXHsyB+kHIZm5RNDl/K+us33K3rw5skDqedCgiJX CBDU/pGGl0xLhbOIJGb1vM/ZzQHypJUbbp3o/l9y5hwg5mds1B8reOvaRZEajxKF sQX8CnAv2Jsj4UOwePQw0bTWlvRq/Ah1aAsxDHaEaiCDwMpclk2a+l1QR1LqF+41 zCEYqT1F84kaYTcl7VRcIsuWIXfN79h7S4s3NhvtfQJP8EZAYCiIx2/NEsEoiSyN uezyZQVs/UaYowEj2DgelfOyIJjbXnzL1nXmqvxHKrUlSSOcGgEnN4rJNPh+ExSJ aZHTcZrHDSQsXBV7OIYYhR4RGWst5oS1Co0UUBEwCbM8DlAIfm+xu1zu3RhSsMag b+Zahh21Ne9CxGBAaio5rN9Ij02hUgH6+fyl8nO82Lcq8OYIS2hTc38PpJ+LuH7T znWz2xCn5TOFO5eWzWGU9w=╢DH
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usen

XPost: linux.debian.devel.mentors

Hello,

On Wed 28 May 2025 at 10:04pm +02, Marc Haber wrote:

My personal pet peeve is the difference between the source package and the packaging git repository contents. Those two especially differ in the state of
patches: They're applied in the unpacked source package, and not applied in the packed source package and in the git repository contents. That is for me a
constant source of confusion and it would be nice if your document would contain an explanation.

To be clear, there are several patches-applied workflows (where both
d/patches and the changed files are committed to git) in use in the
archive by high profile packages. For example, Emacs.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmg4KG0ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQMccEACfmEYAJBba2oxN/r7qasw1 0JrAJ8RK/7TnNYYYikPxUbuFuJQqo6wg8hzrC0wBUcGANN5xlyRAnqGwz3lk7squ Zho88YPON608iv//ELp+/FUemYRt9ybwON+Tuh4qC2far39S/A4XU15rRQYSrWiC 9Tl7N4hliuSjIyQEGVCLIkClcQNVfXnq3b4InTbwBTJ0SOjq/cySbyqiAX+2AAxL lk4RNgdb94RsLol4nM4gtmPAcEte3cwOjH2mvBh0sEH2dj3vdKKHKOM2K+ThMR0p o+pySe9t6vYOXwbD8J+xrDxi7KLd4iHLE/oJ+eQj9YhzQqp5Y8+5tZlrZvS4EtGp sbCwAeu2I4NzcSdEoelxT3WERz8zWqlUjYida9bEHoOS9TfxXz4dTLfOsJUPc2sP JCA9kDXUnLLkfuv4nUviXftqY9uLUfLxfEwgoccuOtBMZ7uEQeXdst6CrJx7kgJC er80gjdh+H1BREMnEYUbgFNGsBbRdd/a5ifU4Ygvi8mJ/duHrITQKbn6VnsM/pwP /ZaJOzMJOZcXXoVITBEraZZqkeVpg+UQCW8mUJjVh/HHyYpLjRubYR1nV4Qk4Y/f gr/mEbifNOs9M4D7KzEgbTJTtN9IjUCk6Jav+PoxPAO4HXYmy1CKRw+tgzu70Chz uv4JfhbPXt7rCv75CEFtpg==GEYS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

XPost: linux.debian.devel.mentors

On Thu, May 29, 2025 at 10:27:09AM +0100, Sean Whitton wrote:

On Wed 28 May 2025 at 10:04pm +02, Marc Haber wrote:

My personal pet peeve is the difference between the source package and the >> packaging git repository contents. Those two especially differ in the state of
patches: They're applied in the unpacked source package, and not applied in >> the packed source package and in the git repository contents. That is for me a
constant source of confusion and it would be nice if your document would
contain an explanation.

To be clear, there are several patches-applied workflows (where both >d/patches and the changed files are committed to git) in use in the
archive by high profile packages. For example, Emacs.

Again, Otto outlined HIS personal preference to create packages, he did
a marvelous job in explaining WHY he prefers THIS workflow and I
personally happen to concur.

Greetings
Marc

-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.mentors

Hello,

On Thu 29 May 2025 at 11:31am +02, Marc Haber wrote:

On Thu, May 29, 2025 at 10:27:09AM +0100, Sean Whitton wrote:

On Wed 28 May 2025 at 10:04pm +02, Marc Haber wrote:

My personal pet peeve is the difference between the source package and the >>> packaging git repository contents. Those two especially differ in the state of
patches: They're applied in the unpacked source package, and not applied in >>> the packed source package and in the git repository contents. That is for me a
constant source of confusion and it would be nice if your document would >>> contain an explanation.

To be clear, there are several patches-applied workflows (where both >>d/patches and the changed files are committed to git) in use in the
archive by high profile packages. For example, Emacs.

Again, Otto outlined HIS personal preference to create packages, he did a marvelous job in explaining WHY he prefers THIS workflow and I personally happen to concur.

Right. Opinionated posts are very useful.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmg4LI0ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQO8jD/91ZDessAbbfhtaUUPSxuQO 0rHdkzzx7M9KJE+0V6vvS3gR9jDL+bdzip0/NVIymOVcN3C6v/7VzcqifNvKY3FL tOb5LqSEZSaP83nZMBwa3KQGQka0wkDomK9k9iBscIIhNDbQFWYy/QMNL3mJpqgz E6DXn4aIwoSlPJGc/ERlgLwHUlJ7gayLzHwyjF/4My/2WEsfMeaVWEA2vorMHkMw mYfzYnbXlsZWOg8T+hU3fsvy154MbMmGUFYZ6KY/7WYXX/aYIMTHYN+KLuJOUSiA vilwnzc9OxCO0L2a/CsBjnVP3J4iG8oUKKykloD+2iNUBYgu2q38VaGrCMO33XUt 6WEmR4K1IiGn5AhGiGVZ1lVUz2JE3o4sD4wX0WVFH/1WWrWfvAmnxLMuZtTdmue3 /l6IF7aXkTVRRUis9FSNhnR/ruUNv39gOEqGjkpmJHxmaJcptdkL/EqsHuIbtbiq YXoN1SbbF5TOiW1A+FA90nIzkqm9pgbMOm2p1Bd8uCI/gGz8QfLMsnZzol4zFNDI wrZUnu+6oFFO+VpEP0nDSu7n1DcbItN4ZHXXACTxnAkMznfksPvXlStRyUSwsmo7 YUWss/K5xRV2/fOaANb5vNMfnEpDJ4+ywmXtEHEwOQzQxrI6zyFRwKJhfk6zD0fV 9rDwEZwjBgr0NZcEBLXtRQ==N22j
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Hi,

Perhaps, to ease the burden of those of us maintaining many packages,
we could instead have this more complex rule:

The default debian branch is the first available of these, in order:
1. debian/latest
2. debian/unstable
3. debian/experimental

If no other information was available the above "algorithm" would make
sense, but please don't forget that git *always* has the _default
branch_ information available.

People contributing to a package in Debian should always target the
default branch in the packaging git repository.

I didn't write the DEP-14, but to my understanding it has been
recommending 'debian/latest' since 2020 because reusing the default
git name 'main' as 'debian/main' would cause confusion, and out of
other options such as 'master' and 'trunk' the authors of DEP-14
landed on 'latest' as something that is descriptive enough yet not
conflicting with other concepts.

DEP-14 also states that as a secondary option 'debian/unstable' is
allowed. However as Xiyue writes, that causes extra work for managing transitions if uploads to experimental are done and
'debian/experimental' introduced.

Most of the time the uploads to experimental are one-off quality
assurance things, and the decision to do so is done at release time or
close to release time. I don't think it would make sense for people to
upload to experimental from a branch called 'debian/unstable', nor do
I think it would be time well spent to go and flip the default branch
setting from 'debian/unstable' to 'debian/experimental' in the git
repo and ask all contributors to rebase their MRs on
'debian/experimental' a few days before preparing such an upload.

Sometimes the uploads to experimental are used because there is a
freeze, like now. Again it is much simpler to continue to do commits
to 'debian/latest' and keep it as the git default branch than to do
the work of switching branch names. When the git commits and
contributions are made people won't necessarily even know if the
freeze will be over by the time that package uploads, so managing
branch name changes might be unnecessary. To me it seems clearly
better to just target 'debian/latest' with all new dev work and make
the unstable vs experimental upload purely a decision at upload time.

Some large packages might also use uploads to experimental for testing
new features. In that case the 'debian/latest' branch should still
remain the default branch, and the feature development be done on a
feature branch (with whatever name).

In some cases the package may need to be maintained in unstable with
only bugfixes without blocking other development in version control.
In those cases it still makes sense to keep 'debian/latest' as the
development head and target all improvements there, but branch off 'debian/unstable' as a maintenance branch.

Anyway, whatever you choose, please make sure that the branch you use
as the development head branch is on Salsa marked as the default git
branch to clearly communicate to contributors what branch they should
target submissions on.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)