Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Q. What is the best practice about +dfsg and +ds extension?
104 views
Skip to first unread message
Kentaro Hayashi
Oct 2, 2021, 8:40:02 AM10/2/21
to
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 “dfsg” or “ds” 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 <ken...@xdump.org>
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 “dfsg” or “ds” 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 <ken...@xdump.org>
Jonas Smedegaard
Oct 2, 2021, 9:10:03 AM10/2/21
to
Quoting Kentaro Hayashi (2021-10-02 14:19:17)
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
> 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
> As far as I know, it is not well documented as a policy or devref.
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
Timo Röhling
Oct 2, 2021, 9:20:03 AM10/2/21
to
* Jonas Smedegaard <jo...@jones.dk> [2021-10-02 15:03]:
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 │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
>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
>later release with the issues fixed, without needing ugly versioning or
>being forced to wait for a later upstream release.
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 │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
Jonas Smedegaard
Oct 2, 2021, 9:30:03 AM10/2/21
to
Quoting Timo Röhling (2021-10-02 15:12:04)
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 Smedegaard <jo...@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
> >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.
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.
Adam Borowski
Oct 2, 2021, 11:50:03 AM10/2/21
to
On Sat, Oct 02, 2021 at 03:12:04PM +0200, Timo Röhling wrote:
> * Jonas Smedegaard <jo...@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
> * Jonas Smedegaard <jo...@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.
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!
⠈⠳⣄⠀⠀⠀⠀
Russ Allbery
Oct 2, 2021, 12:10:02 PM10/2/21
to
Jonas Smedegaard <jo...@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
> 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.
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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
Sean Whitton
Oct 2, 2021, 4:40:03 PM10/2/21
to
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
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").
--
Sean Whitton
Kentaro Hayashi
Oct 5, 2021, 12:40:03 AM10/5/21
to
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 <jo...@jones.dk>:
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 <jo...@jones.dk>:
Russ Allbery
Oct 5, 2021, 1:00:02 AM10/5/21
to
Kentaro Hayashi <ken...@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
> 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
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.
Raphael Hertzog
Oct 6, 2021, 4:40:03 AM10/6/21
to
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. :-)
> > 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" :)
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <her...@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Kentaro Hayashi
Oct 7, 2021, 7:20:02 AM10/7/21
to
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 <r...@debian.org>:
--
Kentaro Hayashi <ken...@gmail.com>
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 <r...@debian.org>:
Kentaro Hayashi <ken...@gmail.com>
0 new messages