• 1.0 format with direct changes in diff (Was: Debian Trends updated)

    From Lucas Nussbaum@21:1/5 to Bastian Blank on Thu Apr 8 16:10:02 2021
    Hi Bastian,

    On 08/04/21 at 11:33 +0200, Bastian Blank wrote:
    Hi Lucas

    On Wed, Apr 07, 2021 at 02:03:47PM +0200, Lucas Nussbaum wrote:
    - source format 1.0 with direct changes in .diff.gz (no patch system)

    For this I disagree. At least until we have something acceptable that
    can be used in modern git workflows including operations like cherry
    picking and merge requests.

    Is that a real issue in practice? If you can export the changes made to upstream sources as a single big diff, surely you can also export them
    as separate patches in 3.0 (quilt)?

    I looked at whether packages with the "direct-changes-in-diff-but-no-patch-system" lintian tag were using a
    VCS, and the result is:

    udd=> select vcs_type, count(*) from sources_uniq
    where (source, version) in (select distinct package, package_version from lintian where tag='direct-changes-in-diff-but-no-patch-system')
    and release = 'sid'
    group by vcs_type;
    vcs_type | count
    ----------+-------
    Bzr | 2
    Cvs | 1
    Git | 67
    Svn | 4
    (null) | 323
    (5 rows)

    So the vast majority of them are also part of the set of packages that
    are not maintained in a VCS.

    Of the 67 maintained with Git, only half of them (32) are hosted on
    salsa, and one fifth still points to alioth. For the 28974 packages in unstable maintained with Git, 23774 use salsa (82%) and 14% still point
    to alioth. So it seems that the packages with direct changes in diff.gz
    and maintained with git are generally lagging a bit more than the
    average package in terms of packaging practices.

    Lucas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mattia Rizzolo@21:1/5 to Lucas Nussbaum on Thu Apr 8 16:50:02 2021
    On Thu, Apr 08, 2021 at 04:01:38PM +0200, Lucas Nussbaum wrote:
    On 08/04/21 at 11:33 +0200, Bastian Blank wrote:
    On Wed, Apr 07, 2021 at 02:03:47PM +0200, Lucas Nussbaum wrote:
    - source format 1.0 with direct changes in .diff.gz (no patch system)

    For this I disagree. At least until we have something acceptable that
    can be used in modern git workflows including operations like cherry picking and merge requests.

    Is that a real issue in practice?

    Whatever the case, past discussions all proved that this point is
    contentious. For now I'd just give up in normalizing this case in
    favour of all the other smells and all the other cases for now (like
    1.0+random patch system). I'm sure once the number of 1.0 goes down
    more and more this topic will find a solution by itself.
    The number of 1.0 with direct changes is small enough that I don't think
    the random passerby has many changes to change upon and be confused by
    it, so the effort required to make people agree is IMHO not worth it at
    this point in time.

    If you can export the changes made to
    upstream sources as a single big diff, surely you can also export them
    as separate patches in 3.0 (quilt)?

    FWIW, please don't forget the single-debian-patch option for
    dpkg-source, but still I'd rather not drag a discussion on this topic
    once again.

    --
    regards,
    Mattia Rizzolo

    GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
    More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'`
    Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

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

    iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAmBvFncACgkQCBa54Yx2 K62OWw//bg3ntDygjfqeun+mSsO4Bl9c9Zx0iTGuQx+fN/eAOTiPE0GUNtTm/0En wfg7aK7Hw6Kvj8pdP+iMHyLnMm6P7zwya/v7Obxabyk4eXbSNyJN5NV82+dO2SoT 6G4dgl6vGY01GM/BJ5fPPv6se4S/IC5jN9WWQ32rH6t+ss1aZqoT17INPfqDfAzH 5gZCBdlwMW+/3/RCbn3pMYyjgp2W05lxrb4CrWZqpblMKMVO8yNfvww5KKl5RN0u 8BYuG5+nDg/rDE6EFi4ggA9uvyVvxYCv6FtjrERFDhosehWjg5D9Ygu+PJ7CcQhY 3iHlO5zG7Doy/a7eIne61sxtADkobWqTtc3tSZhSY61oJLBVn0hKYoNAlTpY6+89 hBas3r7tjIC2oy/3XIefgbMeMZvhfpBLfvHN/tE1TX5iAN1CS/age7mfreN6egOV J/x+58WPHUPTzCpXVaF0uMfelp6blQNGBs1fYywqtQYYzWfD6C+1JMBLD19cA2yS 29AfxNq7w5pVnzSg+LaossYbNx81Of0J+lHHuLt6LMONVkYjfXc
  • From Bastian Blank@21:1/5 to Lucas Nussbaum on Thu Apr 8 23:20:01 2021
    Hi Lucas

    On Thu, Apr 08, 2021 at 04:01:38PM +0200, Lucas Nussbaum wrote:
    Is that a real issue in practice? If you can export the changes made to upstream sources as a single big diff, surely you can also export them
    as separate patches in 3.0 (quilt)?

    How do you export changes? And no, creating separate patches breaks as
    soon as the history is not linear, like after merging a new upstream
    release. Sure, you could rease, but that is not an automatic process.

    Bastian

    --
    Without facts, the decision cannot be made logically. You must rely on
    your human intuition.
    -- Spock, "Assignment: Earth", stardate unknown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Raphael Hertzog@21:1/5 to Raphael Hertzog on Fri Apr 9 11:00:01 2021
    On Fri, 09 Apr 2021, Raphael Hertzog wrote:
    "debian-single-patch" option (that you can put in debian/source/options)

    "single-debian-patch", sorry

    https://manpages.debian.org/buster/dpkg-dev/dpkg-source.1.en.html#Format:_3.0_(quilt)

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Raphael Hertzog@21:1/5 to Bastian Blank on Fri Apr 9 10:50:01 2021
    Hello,

    On Thu, 08 Apr 2021, Bastian Blank wrote:
    How do you export changes? And no, creating separate patches breaks as
    soon as the history is not linear, like after merging a new upstream
    release. Sure, you could rease, but that is not an automatic process.

    As Mattia pointed out, the "3.0 (quilt)" format supports the "debian-single-patch" option (that you can put in debian/source/options)
    which makes it behave like source format 1.0 and auto-generates/updates a single patch in the series based on the changes you made compared to
    upstream.

    I don't think there's a valid technical reason to not use a newer format.
    Some dislike the choices made and the fact that many new features are
    coupled to the new format, but there's really nothing that you could do
    with the old format than you can't do now with new ones.

    (Except using a version with a Debian revision with a native package)

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adam Borowski@21:1/5 to Raphael Hertzog on Fri Apr 9 12:40:01 2021
    On Fri, Apr 09, 2021 at 10:42:22AM +0200, Raphael Hertzog wrote:
    As Mattia pointed out, the "3.0 (quilt)" format supports the "debian-single-patch" option (that you can put in debian/source/options) which makes it behave like source format 1.0 and auto-generates/updates a single patch in the series based on the changes you made compared to upstream.

    I don't think there's a valid technical reason to not use a newer format. Some dislike the choices made and the fact that many new features are
    coupled to the new format, but there's really nothing that you could do
    with the old format than you can't do now with new ones.

    I suspect people resent being chastised to "separate patches" as the
    toolage used to scream at you when using 3.0 + single-debian-patch.


    Meow!
    --
    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁
    ⢿⡄⠘⠷⠚⠋⠀ A true bird-watcher waves his tail while doing so. ⠈⠳⣄⠀⠀⠀⠀

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lucas Nussbaum@21:1/5 to Adam Borowski on Fri Apr 9 13:20:01 2021
    Hi Adam,

    On 09/04/21 at 12:33 +0200, Adam Borowski wrote:
    On Fri, Apr 09, 2021 at 10:42:22AM +0200, Raphael Hertzog wrote:
    As Mattia pointed out, the "3.0 (quilt)" format supports the "debian-single-patch" option (that you can put in debian/source/options) which makes it behave like source format 1.0 and auto-generates/updates a single patch in the series based on the changes you made compared to upstream.

    I don't think there's a valid technical reason to not use a newer format. Some dislike the choices made and the fact that many new features are coupled to the new format, but there's really nothing that you could do with the old format than you can't do now with new ones.

    I suspect people resent being chastised to "separate patches" as the
    toolage used to scream at you when using 3.0 + single-debian-patch.

    Can you give an example?

    Lucas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adam Borowski@21:1/5 to Lucas Nussbaum on Sat Apr 10 13:40:02 2021
    On Fri, Apr 09, 2021 at 01:09:43PM +0200, Lucas Nussbaum wrote:
    On 09/04/21 at 12:33 +0200, Adam Borowski wrote:
    On Fri, Apr 09, 2021 at 10:42:22AM +0200, Raphael Hertzog wrote:
    I don't think there's a valid technical reason to not use a newer format. Some dislike the choices made and the fact that many new features are coupled to the new format, but there's really nothing that you could do with the old format than you can't do now with new ones.

    I suspect people resent being chastised to "separate patches" as the toolage used to scream at you when using 3.0 + single-debian-patch.

    Can you give an example?

    Recently fixed so it's no longer a concern in Bullseye -- that's why I said "used to", in past tense. Still, a lot of developers use Buster and older
    on their boxes.

    IIRC such messages were given by:
    * patch header
    * lintian
    * mentors.debian.net

    But even if the messages are gone now, people still remember being told so.


    Another sometimes mentioned downside of 3.0+s-d-p is doubling the debian/ directory if it's present in upstream releases. I believe this is a bogus reason as all these files are supposed to be tiny.


    Meow!
    --
    ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
    ⣾⠁⢠⠒⠀⣿⡁ # beware of races
    ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
    ⠈⠳⣄⠀⠀⠀⠀ `----

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