@@ -1098,19 +1098,31 @@ Let's get rid of that one too.
10981098### Downloading source
10991099Using ` git ` to download sources is not acceptable in 99% of situations. As
11001100mentioned in [ quality requirements] ( #quality-requirements ) , only ** released,
1101- stable programs are packaged** . Pulling directly from ` HEAD ` is wrong. Releases
1102- or tags should be preferred.
1101+ stable programs are packaged** .
1102+
1103+ As mentioned in the beginning of this page, this tutorial focuses on packaging
1104+ j4-dmenu-desktop version ** r2.18** . But that is not what we've been packaging
1105+ so far. ` git clone https://github.com/enkore/j4-dmenu-desktop.git ` was
1106+ invoked to fetch j4-dmenu-desktop, which downloads the ** latest development
1107+ version** [ ^ fixgit ] . This hinders reproducibility, and it makes the package less
1108+ reliable.
1109+
1110+ Pulling directly from ` HEAD ` is wrong. Releases or tags should be preferred.
11031111
11041112Releases can be found on the right-side panel on GitHub:
11051113
11061114![ GitHub release side panel] ( ../images/j4-dmenu-desktop/github_release_side_panel.png )
11071115
1116+ Scroll down until you see r2.18:
1117+
1118+ ![ GitHub release] ( ../images/j4-dmenu-desktop/github_release.png )
1119+
11081120Some projects include prebuilt binaries in their releases. You mustn't use them
11091121if you want your package to be included in
11101122[ void-packages] ( https://github.com/void-linux/void-packages ) . You should choose
11111123the ` Source code (tar.gz) ` option:
11121124
1113- ![ GitHub release] ( ../images/j4-dmenu-desktop/github_release .png )
1125+ ![ GitHub release asset ] ( ../images/j4-dmenu-desktop/github_release_asset .png )
11141126
11151127You can then put this into the ` distfiles ` variable.
11161128
@@ -1634,3 +1646,6 @@ packaging another program, [`bat`](https://github.com/sharkdp/bat):
16341646[ ^ bytecompiled ] : Python packages are _ byte compiled_ on Void, but that is
16351647 something different.
16361648[ ^ buildstyledeps ] : Not all build styles do that.
1649+ [ ^ fixgit ] : ` git ` can be invoked with ` --branch r2.18 ` to package the correct
1650+ version, but that also pulls unneeded git history, and it is more
1651+ difficult to verify its state (SHA256SUMs are used for tarballs).
0 commit comments