Hi,

I want to know about the best practice of +dfsg and +ds extension.
As far as I know, it is not well documented as a policy or devref.

In practical side of view, it seems that it varies on each maintainer.
Most well formalized document is "Choose a repack suffix" [2],
addtionally, mentors.d.n FAQ [2] introduces repack count too.

It seems that it was filed [3] already, but not resolved yet.

I've checked udd information for sid, here is the result of the numbers of +dfsg is used packages. The vast majority is +dfsg-1 style.

A. +dfsg-1 1461 (no repack count)
B. +dfsgN-1 400 (use N repack count)
C. +dfsg.N-1 57 (use .N repack count)

It seems that it should be +dsfg-1, but is repack count (B. or C.)
still recommended way to be contained?
If so, which style is recommended (B. +dfsgN-1 or C. +dfsg.N-1 style)?
I'm not sure whether there is a consensus about this topic.

* [1] Choose a repack suffix
https://wiki.debian.org/Javascript/Repacking#A1._Choose_a_repack_suffix
* [2] What does $B!H(Bdfsg$B!I(B or $B!H(Bds$B!I(B in the version string mean?
https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.2BIB0_in_the_version_string_mean.3F
* [3] developers-reference: please explain deb/debian/ds suffixes in versions
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499167

In the past, related topic is discussed but it is not for the repack count.
* https://lists.debian.org/debian-mentors/2010/03/msg00325.html
* https://lists.debian.org/debian-mentors/2019/08/msg00108.html

Regards,

--
Kentaro Hayashi <kenhys@xdump.org>

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

Quoting Kentaro Hayashi (2021-10-02 14:19:17)

I want to know about the best practice of +dfsg and +ds extension.
As far as I know, it is not well documented as a policy or devref.

When upstream codebase in its pristine form would violate the Debian
Free Software Guidelines (DFSG), I would use the hint "dfsg"-

When upstream codebase require repackaging for (only) other reasons than
DFSG compliance I instead use the hint "ds" (as in "derived source").

I use ~ (tilde) as delimiter when possible, to make room for an eventual
later release with the issues fixed, without needing ugly versioning or
being forced to wait for a later upstream release.

I use + (plus) as delimiter when I cannot use ~ (tilde).

Since you tried mentioned some statistics: It is indeed more popular to
favor + over ~ but "popular practice" does not equal "best practice".


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============P84079588632345802=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-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFYWJ8ACgkQLHwxRsGg ASFLZxAApCkRF4vtyv7XeJawVpQj+BNFQWYTVIjEu3ky3tzfoOxEAnQ4V7IGB0hd vaU9Q2hlMZrSQWZABtRLqD5Jex85RPzxJynyxxpD/ooFV2Dyb2dOP5Wp9fZCKdl9 3F5/54rXwkhIUAKbtC0JzB+TezcMDOUk1M7hiGM2YwYqs5rTb7C8GxQjsMDZZ4Kr 5Jv0gR/sWUBdCpEd5Uvoqj5KhIvE2Gpw4f9X+t2qnlufTVtZRqqvPQk7TvFtsZLo kWaC3OkTMfATGB3cWFFTnBa/do+Qb/AF++EFkL5kCeBU5USdGqEczjhLi12w6vmU KKsARMln9lBV4yMEkqIX9uTzRukC6LbbAWj9yKKN15BuHw4nNH/Z7A7+/6aowdVV lCd4Xa+loYtHqCZEsz/afl3Vu9Jyp0WME8GEyoJE6m1IQJlgVh2J/q5XZlTCnbTe nmcTgyjqZLGizwbIfZEvXZLHme8V5H6IN3LGGaRAWIyn9UlSvQTAvgWA1HtYFtmp pq8XLDPMWq/fJ47Za

Quoting Timo Röhling (2021-10-02 15:12:04)

* Jonas Smedegaard <jonas@jones.dk> [2021-10-02 15:03]:

I use ~ (tilde) as delimiter when possible, to make room for an
eventual later release with the issues fixed, without needing ugly >versioning or being forced to wait for a later upstream release.

Has this actually ever happened? I would expect that most upstream
authors would rather create a new patch release than retroactively
change the contents of an existing one.

I haven't kept track, but I seem to recall that indeed it has been of
use - not because upstream did a re-release with different content (I
agree that would be rare) but instead a licensing concern later resolved
- i.e. an upstream pristine tarball considered DFSG-incompatible at
first but later (e.g. through conversations with upstream or discussions within Debian) it turns out that indeed that very tarball does comply
with DFSG.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============76224683795394434=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-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFYXQwACgkQLHwxRsGg ASGcSQ//fBahPKflcVuhMntpxQfFzfwOYaPRstk2AHLxJtDthNw9PmhHuvbVL8ty ph+f4VgzAYawweEyAQH4J9PsjzS35ckgDC0RvY9picGCwI6RC6EsjLZptV7CuU/I 8avDwm+B/g5X++JxQPpU/KIL5xqL/BUiJhemN5qcOaDsD6BY5LGuxbYhvLkLMoee QaEA7DPV30r7U8+Tfy/i9vxHdDH0DtXts4fz/6QQvHaWH+DLMNHCSgqCZYnQRZQ9 BIC1Dke4bldGjCqlaHVlUG9DyejDtj2uHiOlhsYQizvBZ2b0mTFAGL1gVx1CT5do nYGq+I07jXLkDIirZ7RQ8C4Fpe5g0tn2FEx+tCtB9iAMwmRkffiXgxVmfOFvPRf4 kmDW+2ScbQHH0eOBEP8sxZFbKcd762Yae/5FMqNv3V7njLsdr6UQt6oJ3Gz3ygPZ noEkIRrr1lylwr5DnPe4aRM48XLwYeNetalVlLm/D5ypyw7323dyOQU/XmcKDDFp bUiMJdmN9OB5sMiw9

* Jonas Smedegaard <jonas@jones.dk> [2021-10-02 15:03]:

I use ~ (tilde) as delimiter when possible, to make room for an eventual >later release with the issues fixed, without needing ugly versioning or
being forced to wait for a later upstream release.

Has this actually ever happened? I would expect that most upstream
authors would rather create a new patch release than retroactively
change the contents of an existing one.

Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

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

iQGzBAABCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmFYWqEACgkQ+C8H+466 LVnHKwv/eOK4omANo90YCPYYDPLxLAoncqIYsYQQ23LClDLjeONQ1tLX/R0lN5DJ JNCHTmItjChi3AEwPv5XNafmWUwG2b4uzFRsgRG/maLJ/+EKf1H6omSELkBV/Xsi 2ibmDJ4A0N3vxzi5OMj1SuEztPyUGtG47CqCJ9a5GaQO+SiItjy6BeXX6MwZ3Vvl ls5EdBwZUGpxGqxOKeLty4yHBM9koZ/optkZ3PQ0j4ix7oOzMgtZ1fxJLcrL6dyb C1GJOksDDz+IQpAaVBCNuA/3t6g4jh0LfwcouAAVkNFmopJrNbdFm3MADtfUBlm0 wen8JEyTBkic/GZu016O/BRE5vs7DJda/I51vvZe7Di

On Sat, Oct 02, 2021 at 03:12:04PM +0200, Timo Röhling wrote:

* Jonas Smedegaard <jonas@jones.dk> [2021-10-02 15:03]:

I use ~ (tilde) as delimiter when possible, to make room for an eventual later release with the issues fixed, without needing ugly versioning or being forced to wait for a later upstream release.

Has this actually ever happened? I would expect that most upstream
authors would rather create a new patch release than retroactively
change the contents of an existing one.

If the old version was 1.4, the one with the minor content change (like deleting some Windows binaries) is likely to be called 1.4-nocontrib,
1.4.1 or 1.4a. Using a too high character risks making the altered release
to have a higher version than the upstream.

+ is 0x2b
- is 0x2d
. is 0x2e
~ is less than the empty string


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver!
⠈⠳⣄⠀⠀⠀⠀

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

Jonas Smedegaard <jonas@jones.dk> writes:

I use ~ (tilde) as delimiter when possible, to make room for an eventual later release with the issues fixed, without needing ugly versioning or
being forced to wait for a later upstream release.

The other advantage to using tilde is that if the repackaging to remove non-free source removes functionality as well, this leaves version space
for users who need that functionality for whatever unfortunate reason to package upstream's release as-is and have that version be later than
Debian's version.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

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

Hello,

On Sat 02 Oct 2021 at 03:03PM +02, Jonas Smedegaard wrote:

Quoting Kentaro Hayashi (2021-10-02 14:19:17)

I want to know about the best practice of +dfsg and +ds extension.
As far as I know, it is not well documented as a policy or devref.

When upstream codebase in its pristine form would violate the Debian
Free Software Guidelines (DFSG), I would use the hint "dfsg"-

When upstream codebase require repackaging for (only) other reasons than
DFSG compliance I instead use the hint "ds" (as in "derived source").

Or "Debian source" :)

--
Sean Whitton

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

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

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmFYwdMZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQFl6D/9tyxuzol9sSJm3cs58Okia 7YBefKM1m36xuCOkCidpXGDJvWJFXAJoYW4TBl6NG8Ob0LKlGLZ/7u5M/d79G6UD 9OFSCPGpiEzXglZ3OZu76OLxfejCTkkfDOWVxQ7VHwbHmNqHPyjBC2PtFVbsyvvg ASZpEzFDWZQnoah1IDCgj7sS47DW0CxOevD5HEozmMEbKA05j/Zevvo2/CkUlTwh c2G1eBP9Dwswdhh0ssNMfJ3s43MrCd3eNHtg+K3QqRQ3it87hjMFujPQumB6sS30 dOtuTyNEa+aodhOg08OTstujp3VDcgefWogVC277ratjWXI3i5OGbgypYOxylrFn J51zK4C1thBrPplV2xsN6PCBRfBGUU0KhtlLvn89iK0RktbbVvEKcBR4GgoM7CIU xvmL0ArHZjKPa9JIBDdQZTZ4weQ+c6Agh1Y8e0TNF5neTFWgCEq1P4AYAVYy95OK hAyDf7NLR8Fxeld4u3RyVuygw/e6QtPmRCTaKR3Os+sbo29hElTjaz9aUg3yjuzN N0Ymtk/+6jKCjOWKXuJJUkmgK+qlPGH0wwh4X8G9LZvXZ8LLLN0zKtSrVXPY/q7p DXzspjb93SyS/tS6zYI53dgd2uKdV9JQeHE4SEID7WDDuTXQGwjtoL0AoEfJK0+r s+yQRpQd0+E15H8AwUfyAA==8S6K
-----END PGP SIGNATURE-----

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

Quoting Sean Whitton (2021-10-02 22:32:18)

On Sat 02 Oct 2021 at 03:03PM +02, Jonas Smedegaard wrote:

Quoting Kentaro Hayashi (2021-10-02 14:19:17)

I want to know about the best practice of +dfsg and +ds extension.
As far as I know, it is not well documented as a policy or devref.

When upstream codebase in its pristine form would violate the Debian
Free Software Guidelines (DFSG), I would use the hint "dfsg"-

When upstream codebase require repackaging for (only) other reasons
than DFSG compliance I instead use the hint "ds" (as in "derived
source").

Or "Debian source" :)

Yeah, except that's confusing: Debian subdir is already a "Debian
source" - included as either a patch (with source format "1.0") or a
tarball (with source format "3.0 (quilt)").


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============H58049525178658599=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-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFYyMQACgkQLHwxRsGg ASGpbBAAhvB5SqCzmEQ7APjh6E9sYpNQz+HPajRyF3xhhBJF6UbiYFGfPcFkb89+ K2wKpkoRPO6TMTD9p0xcslf7t1Vg6XmRYmxZRpVJhAnC1zXUcXOtVLap7gofSO90 Sq7dDIGkj0+6UGFAqi0Jk9tGKF6gYbVjOP98H3tguujyuZrxSb1wfjupUXeZACk5 n3T3gL9TGFzG+V2VYN37tTHJxh+qtwOJlj1H+PEVE5kFBTFE/MBJuuOcSDbEnmC+ Ax+3eGxnlq//mHuCgXnXShpGwG0lLuIFujPdRKFSS3pjLp600DFymaqfnNOQAHE7 Fw0s9pAnrJ2RY9ZXhrnZ9ObIyeicW8tCqlJxyc48HivBljSq+xZaUn/ujRgmWMrE M+1MNtWBK99ypZWgY/p8ebQDT4XJs98wZ2z2ibCstNyCUGLoRDlTjRLG5MhpqM4q 7GoeF5wc1nGQa/ajNJqusbZm0HtZZWCaDpHe946wpH6PpAWd8mdPolfnhJzYRCDI 3Ebsn8kRclXqyT0wY

Kentaro Hayashi <kenhys@xdump.org> writes:

What do you think about it?

1. We should use +dfsg-1 style
2. We should use +dfsgN-1 style
3. We should use +dfsg.N-1 style
4. Other

I would start with +dfsg-1 because it's fairly rare to have to iterate on
the repackaging. You can then switch to +dfsgN-1 with the second and subsequent repackagings if needed. (Although if I knew in advance I would probably need to iterate, I'd start with +dfsgN-1.)

There's an argument for consistency to always use +dfsgN-1, I guess, but I don't think it matters enough to bother.

I would not use +dfsg.N-1. It's not consistent with the other places
where we add suffixes, such as backporting and stable updates.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

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

Hi,

Thank you for your explanation.
Very informative.

Reply in this thread talks about +/~, but
I'm curious about repacking count. (Subject may be misleading...)

What do you think about it?

1. We should use +dfsg-1 style
2. We should use +dfsgN-1 style
3. We should use +dfsg.N-1 style
4. Other

Regards,




2021年10月2日(土) 22:03 Jonas Smedegaard <jonas@jones.dk>:

Quoting Kentaro Hayashi (2021-10-02 14:19:17)

I want to know about the best practice of +dfsg and +ds extension.
As far as I know, it is not well documented as a policy or devref.

When upstream codebase in its pristine form would violate the Debian
Free Software Guidelines (DFSG), I would use the hint "dfsg"-

When upstream codebase require repackaging for (only) other reasons than
DFSG compliance I instead use the hint "ds" (as in "derived source").

I use ~ (tilde) as delimiter when possible, to make room for an eventual later release with the issues fixed, without needing ugly versioning or
being forced to wait for a later upstream release.

I use + (plus) as delimiter when I cannot use ~ (tilde).

Since you tried mentioned some statistics: It is indeed more popular to
favor + over ~ but "popular practice" does not equal "best practice".

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private

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

Quoting Russ Allbery (2021-10-05 06:57:00)

Kentaro Hayashi <kenhys@xdump.org> writes:

What do you think about it?

1. We should use +dfsg-1 style
2. We should use +dfsgN-1 style
3. We should use +dfsg.N-1 style
4. Other

I would start with +dfsg-1 because it's fairly rare to have to iterate
on the repackaging. You can then switch to +dfsgN-1 with the second
and subsequent repackagings if needed. (Although if I knew in advance
I would probably need to iterate, I'd start with +dfsgN-1.)

There's an argument for consistency to always use +dfsgN-1, I guess,
but I don't think it matters enough to bother.

I would not use +dfsg.N-1. It's not consistent with the other places
where we add suffixes, such as backporting and stable updates.

Exactly my practice and thinking as well. :-)


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============F61335132926934866=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-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFcCbEACgkQLHwxRsGg ASH/GQ//QendRIyiSYFHhmEtjkGvFS0ftW3BkOOtQ1LmR4IUMH9iBmVadQ7MSICp PMcA8Hv6YQnRl52nlRRrp4MOCoZwiLy1aqZC0w0usgT5HkXo7qEZIGbP4M8qBWP4 NyjcHLf5po08JGCToLoWs4tv1YvIiPskWMXfEZEHaAeJMuHXYKPezK3cyqGuQBYB 3Qxd0TzzKK73ZNdxjJPtqczc+6QXZUnJvkti93nsmYt9h4maa3Lwm2pDv29FZpuU w+8zvoeMtoxewMLSe2i6jFSA6xKqhWPItMCgGNvwHUmL1k7dfkC9yv9RO9W3HCct 7nsnPfn7QZnIoq3n1RvCVItuAwsVXxbz8SIjD4euJAgnNvHBYaeT0L8o/TEQz1wv HFO8NWN3Qm5kjT54NoqLBYMm/MXTOJVwcOtG2XfXnmSg1tOJnf3vnUmohdzNcQh5 u8Bj2Si0upI9LxPJE66V8VRv9pnt2NyMm5CGAYOTQqm4aoyhPwOFyaRBOkv+ITLM DuP006kLBbjlCQvFP

On Sat, 02 Oct 2021, Sean Whitton wrote:

When upstream codebase require repackaging for (only) other reasons than DFSG compliance I instead use the hint "ds" (as in "derived source").

Or "Debian source" :)

I always thought "ds" was for "debian specific" tarball. :-)

Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS

-----BEGIN PGP SIGNATURE-----
Comment: Signed by Raphael Hertzog

iQEzBAABCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAmFdX6EACgkQA4gdq+vC mrnuGQf8DM0NIwBE4mqxEbdExI3+OCc4UMhD8WxqVxj/hj/zQEpqrKCqAN6YPYN4 j6h+zalt3MAKi2pTgLt/bVF/XxjceWVRffNmBmo7yfGqBDGQqTZiqiafAojhoLXI TXXhpEU0PX3Ecp4ucRLj7EPDBdbKYq71l0mcIJHU7wrjDOXuqTgOGtrA9UYrDR0r cQXJo64ZxSP1Lrb9bT2Ox0qB52hXmtbW9Nb7sP272t+0CPefsVriH3FdkNgZHCUP N32ytTtl+DpOMe+V4Tt8ZgarSKOXIo+0axxTlXqIQESflW5Agh+w8c5G1H50Srci a3rYbFiet4j1Vj94FLFeheL7ZR13YA==
=zl5X
-----END PGP SIGNATURE-----

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

Hi,


It seems that it is reasonable to do so.
(Use +dfsg-1 first, then switch to +dfsgN-1)

Thanks!


2021年10月5日(火) 13:57 Russ Allbery <rra@debian.org>:

Kentaro Hayashi <kenhys@xdump.org> writes:

What do you think about it?

1. We should use +dfsg-1 style
2. We should use +dfsgN-1 style
3. We should use +dfsg.N-1 style
4. Other

I would start with +dfsg-1 because it's fairly rare to have to iterate on
the repackaging. You can then switch to +dfsgN-1 with the second and subsequent repackagings if needed. (Although if I knew in advance I would probably need to iterate, I'd start with +dfsgN-1.)

There's an argument for consistency to always use +dfsgN-1, I guess, but I don't think it matters enough to bother.

I would not use +dfsg.N-1. It's not consistent with the other places
where we add suffixes, such as backporting and stable updates.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--
Kentaro Hayashi <kenhys@gmail.com>

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