[pacman-dev] [PATCH] repo-add: should have option to prevent downgrading
Hello, following this report #FS17752 (link at [0]) I made a patch to repo-add From 972a5e88df392042d60e5aea1e52e8c5dd113a69 Mon Sep 17 00:00:00 2001 From: ekardnam <lucabertozzi.pub@gmail.com> Date: Tue, 26 Mar 2019 21:28:39 +0000 Subject: [PATCH] Added --dont-downgrade flag to repo-add as stated in issue #17752 --- scripts/repo-add.sh.in | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in index 57413df5..f8748f08 100644 --- a/scripts/repo-add.sh.in +++ b/scripts/repo-add.sh.in @@ -42,6 +42,7 @@ REPO_DB_SUFFIX= LOCKFILE= CLEAN_LOCK=0 USE_COLOR='y' +DONT_DOWNGRADE=0 # Import libmakepkg source "$LIBRARY"/util/message.sh @@ -63,6 +64,7 @@ Multiple packages to add can be specified on the command line.\n")" printf -- "$(gettext "Options:\n")" printf -- "$(gettext " -n, --new only add packages that are not already in the database\n")" printf -- "$(gettext " -R, --remove remove old package file from disk after updating database\n")" + printf -- "$(gettext " --dont-downgrade do not add package to database if a newer version is already present\n")" elif [[ $cmd == "repo-remove" ]] ; then printf -- "$(gettext "Usage: repo-remove [options] <path-to-db> <packagename> ...\n")" printf -- "\n" @@ -248,9 +250,17 @@ db_write_entry() { return 0 fi else - if (( RMEXISTING )); then - pkgentry=$(find_pkgentry "$pkgname") - if [[ -n $pkgentry ]]; then + pkgentry=$(find_pkgentry "$pkgname") + if [[ -n $pkgentry ]]; then + + local version=$(sed -n '/^%VERSION%$/ {n;p;q}' "$pkgentry/desc") + if (( "$(vercmp $version $pkgver)" > "0" )); then + warning "$(gettext "A newer version for '%s' is already present in database")" "$pkgname" + if (( DONT_DOWNGRADE )); then + return 0 + fi + fi + if (( RMEXISTING )); then local oldfilename="$(sed -n '/^%FILENAME%$/ {n;p;q;}' "$pkgentry/desc")" local oldfile="$(dirname "$1")/$oldfilename" fi @@ -618,6 +628,9 @@ while (( $# )); do -v|--verify) VERIFY=1 ;; + --dont-downgrade) + DONT_DOWNGRADE=1 + ;; *) args+=("$1") ;; -- 2.19.2 ----------Links and stuff--------------- [0] https://bugs.archlinux.org/task/17752?project=3 ekardnam
Hello,
following this report #FS17752 (link at [0]) I made a patch to repo-add
From 972a5e88df392042d60e5aea1e52e8c5dd113a69 Mon Sep 17 00:00:00 2001 From: ekardnam <lucabertozzi.pub@gmail.com> Date: Tue, 26 Mar 2019 21:28:39 +0000 Subject: [PATCH] Added --dont-downgrade flag to repo-add as stated in issue #17752 Thanks for the patch. This seems to be a mailing list resubmission of
On 4/28/19 2:21 AM, ekardnam wrote: the patch that was originally attached to the bugtracker at https://bugs.archlinux.org/task/17752#comment178160 But it was submitted with Thunderbird, which unfortunately does not handle git patches very well... actually, most email clients break patches. Could you resubmit it using `git send-email`? It's very difficult to find any alternative method which is reliable... It is currently a Mime-encoded base64 blob with accompanying PGP signature, which git am does not understand, although patchwork did manage to extract a patch from it... but even so, the email does not apply due to tabs being converted to spaces. Note: All this is mostly described in https://www.archlinux.org/pacman/submitting-patches.html Note2: If you want to add additional notes as described in the Submitting Patches documentation, then you will find the --annotate option to git send-email, to be helpful. ... While I am at it, I would like to suggest slightly tweaking your commit message. You don't need to mention "as stated in issue #17752" in the subject. OTOH, you could/should add "Fixes #17752" as a second paragraph. The patch changes look good to my cursory inspection, so once that is done, we are back to waiting for Allan to do another roundup and pull the latest patches into his queue. :) -- Eli Schwartz Bug Wrangler and Trusted User
Thanks for the feedback, I'll post using git-send-mail later has I'm having some troubles with some perl ssl modules it requires. (I even had read that page but completely forgot about that, sorry about that) Yeah I resubmitted the patch because I thought it went lost, didn't mean to rush you. I thought you may have preffered having the patch on the mailing list rather than in the bugtracker. Thanks for your suggestions, I'll take them into practice in the next patch resubmission using git -send-mail On 28/04/19 07:25, Eli Schwartz wrote:
While I am at it, I would like to suggest slightly tweaking your commit message. You don't need to mention "as stated in issue #17752" in the subject. OTOH, you could/should add "Fixes #17752" as a second paragraph.
The patch changes look good to my cursory inspection, so once that is done, we are back to waiting for Allan to do another roundup and pull the latest patches into his queue. :)
I was suggested by Allan on the bug tracker to use --no-downgrade, then at the time I was writing it it became --dont-downgrade in my head (lol) My initial idea was --keep-latest, but in the end I think --no-downgrade would be the better option (rather than --dont-downgrade).But it can for sure be discussed
Negative options always read a bit oddly. How about the positive --keep-new? That's the sense used in the warning message.
-- Cheers, Ralph. --dont-downgrade is way more clear than --keep-new in my opinion.
On 4/28/19 10:05 AM, ekardnam wrote:
Thanks for the feedback,
I'll post using git-send-mail later has I'm having some troubles with some perl ssl modules it requires. (I even had read that page but completely forgot about that, sorry about that)
Yeah I resubmitted the patch because I thought it went lost, didn't mean to rush you. I thought you may have preffered having the patch on the mailing list rather than in the bugtracker.
Thanks for your suggestions, I'll take them into practice in the next patch resubmission using git -send-mail
The mailing list does get some more viewers, plus it also shows up in patchwork, so to a certain degree we do prefer it on the mailing list. Thanks! I think git send-email should work fine with just the three optdepends listed in `pacman -Qi git`. I hope that helps. :) -- Eli Schwartz Bug Wrangler and Trusted User
Yeah that's why I thought it would be more suitable to resubmit here, I moved the new submit to a new conversation not in reply to this And indeed those dependencies did it, thanks :) On 28/04/19 14:31, Eli Schwartz wrote:
The mailing list does get some more viewers, plus it also shows up in patchwork, so to a certain degree we do prefer it on the mailing list. Thanks!
I think git send-email should work fine with just the three optdepends listed in `pacman -Qi git`. I hope that helps. :)
Hi ekardnam,
+ printf -- "$(gettext " --dont-downgrade do not add package to database if a newer version is already present\n")" ... + warning "$(gettext "A newer version for '%s' is already present in database")" "$pkgname"
Negative options always read a bit oddly. How about the positive --keep-new? That's the sense used in the warning message. -- Cheers, Ralph.
On Sun, 28 Apr 2019 at 13:21, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
Hi ekardnam,
+ printf -- "$(gettext " --dont-downgrade do not add package to database if a newer version is already present\n")" ... + warning "$(gettext "A newer version for '%s' is already present in database")" "$pkgname"
Negative options always read a bit oddly. How about the positive --keep-new? That's the sense used in the warning message.
-- Cheers, Ralph.
--dont-downgrade is way more clear than --keep-new in my opinion.
participants (4)
-
ekardnam
-
Eli Schwartz
-
Morgan Adamiec
-
Ralph Corderoy