| Message ID | tencent_BAFEE47476CAF74BEE6A4336D55217B25E09@qq.com |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
Hello! Thanks for all this work! Having one patch for each KDE package becomes quite unwieldy. I wonder whether we should not do something like I did for Qt in commit 2ac51ec99b58b50c08ba719a8c7e9dba0330b065 - introduce a global variable %kde-version (or local ones in each KDE module); this could be increased once and for all in one commit. If something fails, we could still use a separate version for single packages. Also my impression is that at some point in time, we did have this kind of variable. What do you think? Andreas
Andreas Enge <andreas@enge.fr> writes: > Hello! > > Thanks for all this work! > > Having one patch for each KDE package becomes quite unwieldy. > > I wonder whether we should not do something like I did for Qt in > commit 2ac51ec99b58b50c08ba719a8c7e9dba0330b065 - introduce a global > variable %kde-version (or local ones in each KDE module); this could be > increased once and for all in one commit. If something fails, we could > still use a separate version for single packages. > > Also my impression is that at some point in time, we did have this kind > of variable. > > What do you think? I think is good idea ,will try in next KDE update version, but qt is submodule use same version, dependencies and tests are relatively fixed, kde is more difference program use several identical versions, e.g. KDE frameworks program version is 5.108.0, KDE Plasma program version is 5.27.6, other program version is 23.04.3, if update as sametime, maybe need add more dependency and adjust test, else most of build/test will failed, so it's a big patch. (And won't the guix refresh stop working if i add %kde-version?) > > Andreas
Am Mon, Jul 24, 2023 at 10:11:37PM +0800 schrieb Z572: > kde is more difference program use several identical versions, e.g. KDE > frameworks program version is 5.108.0, KDE Plasma program version is > 5.27.6, other program version is 23.04.3 We could use two different variables for frameworks and plasma: (define-public %kde-framework-version "5.108.0") (define-public %kde-plasma-version "5.27.6") and, if they are all different, version other programs one by one, or if the majority has the same version add yet another variable. > (And won't the guix refresh stop working if i add %kde-version?) That should still be fine, it will not notice the difference if the version is given through a string or a string "variable" (which is in fact a constant). If we go for this route, I would start from the beginning: Introduce the variables at their current values in one commit, which should have no impact on the resulting packages, then try to update them and see what QA has to say about it. iyzsong, what do you think? Andreas
Andreas Enge <andreas@enge.fr> writes: > Am Mon, Jul 24, 2023 at 10:11:37PM +0800 schrieb Z572: >> kde is more difference program use several identical versions, e.g. KDE >> frameworks program version is 5.108.0, KDE Plasma program version is >> 5.27.6, other program version is 23.04.3 > > We could use two different variables for frameworks and plasma: > (define-public %kde-framework-version "5.108.0") > (define-public %kde-plasma-version "5.27.6") > and, if they are all different, version other programs one by one, > or if the majority has the same version add yet another variable. > >> (And won't the guix refresh stop working if i add %kde-version?) > > That should still be fine, it will not notice the difference if the > version is given through a string or a string "variable" (which is > in fact a constant). no, it cann't work, like it: ``` From https://download.kde.org/stable/release-service/23.04.3/src/ark-23.04.3.tar.xz... following redirection to `https://kde.cs.nycu.edu.tw/ftp/stable/release-service/23.04.3/src/ark-23.04.3.tar.xz'... ….3.tar.xz 2.9MiB 2.9MiB/s 00:01 ▕██████████████████▏ 100.0% gnu/packages/kde-utils.scm:54:2: ark: updating from version 22.04.3 to version 23.04.3... gnu/packages/kde-utils.scm:54:2: warning: ark: no `version' field in source; skipping ``` see attache photo. > > If we go for this route, I would start from the beginning: > Introduce the variables at their current values in one commit, which > should have no impact on the resulting packages, then try to update them > and see what QA has to say about it. > > iyzsong, what do you think? > > Andreas
Hello, I could look into this next days, maybe create a kde-updates branch for review. Thanks! Z572 <873216071@qq.com> writes: > Andreas Enge <andreas@enge.fr> writes: > >> Am Mon, Jul 24, 2023 at 10:11:37PM +0800 schrieb Z572: >>> kde is more difference program use several identical versions, e.g. KDE >>> frameworks program version is 5.108.0, KDE Plasma program version is >>> 5.27.6, other program version is 23.04.3 >> >> We could use two different variables for frameworks and plasma: >> (define-public %kde-framework-version "5.108.0") >> (define-public %kde-plasma-version "5.27.6") >> and, if they are all different, version other programs one by one, >> or if the majority has the same version add yet another variable. >> >>> (And won't the guix refresh stop working if i add %kde-version?) >> >> That should still be fine, it will not notice the difference if the >> version is given through a string or a string "variable" (which is >> in fact a constant). > > no, it cann't work, like it: > ``` > From https://download.kde.org/stable/release-service/23.04.3/src/ark-23.04.3.tar.xz... > following redirection to `https://kde.cs.nycu.edu.tw/ftp/stable/release-service/23.04.3/src/ark-23.04.3.tar.xz'... > ….3.tar.xz 2.9MiB 2.9MiB/s 00:01 ▕██████████████████▏ 100.0% > gnu/packages/kde-utils.scm:54:2: ark: updating from version 22.04.3 to version 23.04.3... > gnu/packages/kde-utils.scm:54:2: warning: ark: no `version' field in source; skipping > ``` > > see attache photo. Oh, that's not ideal. > >> >> If we go for this route, I would start from the beginning: >> Introduce the variables at their current values in one commit, which >> should have no impact on the resulting packages, then try to update them >> and see what QA has to say about it. >> >> iyzsong, what do you think? >> >> Andreas That's fine, but since it seems 'guix refresh' doesn't update hashes when version is not inline, some work is needed for the 'refresh' command. I think we could look into group versions after this merge.
diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm index a79338f84e..aea027013a 100644 --- a/gnu/packages/qt.scm +++ b/gnu/packages/qt.scm @@ -285,7 +285,7 @@ (define-public materialdecoration (define-public grantlee (package (name "grantlee") - (version "5.2.0") + (version "5.3.1") (source (origin (method git-fetch) @@ -294,7 +294,7 @@ (define-public grantlee (commit (string-append "v" version)))) (file-name (git-file-name name version)) (sha256 - (base32 "02dyqxjyxiqxrlz5g7v9ly8f095vs3iha39l75q6s8axs36y01lq")))) + (base32 "1ipnkdi8wgv519mvwa5zxlz20wipbypyfixjv2qdfd9vl1pznwvs")))) (native-inputs ;; Optional: lcov and cccc, both are for code coverage (list doxygen))