Revert on downgrade effects
kostadinnm opened this issue Β· comments
π Feature Request
Background
Hello.
I'd like to propose an enhancement, which should be quite easy to implement, I guess.
I've downgraded a dependency of a package that refused to upgrade. Now, a new version of my main package is released, but I need to use other tool(pacman
) to revert the effects of the downgrade. I'd memoize easier, if utilizing the same command interface for downgrading and reverting the downgrade actions.
Proposed feature
downgrade
should be able to revert package version freeze.
Thanks for describing this feature request.
If I understood you correctly, you propose a new feature where downgrade
reverts its last action and restores a downgraded package back to its original version before the downgrade. Is this correct? If I got it wrong, it would be good if you could provide a specific example with mock packages/versions.
As of now, the only way of tracking downgraded packages would be to look at the IgnorePkg
definition in /etc/pacman.conf
and assume all packages there have been explicitly downgraded. Because no information on the pre-downgrade package version is tracked, it would not be possible to revert the action of downgrade back to the (specific) old version.
However, I could imagine the following new CLI option:
# downgrade --revert <pkg>
This would trigger the following workflow:
- Check if the package is defined in
IgnorePkg
- If it is, remove its definition from
IgnorePkg
- Then execute
pacman -S <pkg>
to update the package to the latest version upstream
@kostadinnm would this workaround still be useful for your use-case?
@pbrisbin WDYT? I could imagine this feature request being a part of #118 since it also involves non-interactive actions similar to the ones mentioned in the issue.
Well, you know me, I'm always trying to find ways for downgrade
to be useful with other tools, instead of taking over their tasks...
What do you think of
downgrade --unignore [pkg...]
The --unignore
flag causes downgrade
to remove anything present in IgnorePkg
. The pkg
argument is optional, can be specified multiple times, and filters what it will actually remove. It then prints, one per line, the packages that were affected.
Because of the printing, you could do:
downgrade --unignore | pacman -S -
WDYT?
To go fully good-oss-citizen, we could consider extracting the parts of downgrade
that interact with IgnorePkg
to a separate executable, something like
pacignore ls|add|rm [pkg...]
and see if we can get that added to pacman-contrib
. Then downgrade
could just use it, and this specific feature would end up being provided by that instead:
pacignore rm | pacman -S -
Yes, atreyasha, that was exactly what I mean.
As to what pbrisbin have added, that is more comprehensive than I can imagine.
Well, you know me, I'm always trying to find ways for downgrade to be useful with other tools, instead of taking over their tasks...
And thanks for doing that :)
The --unignore flag causes downgrade to remove anything present in IgnorePkg. The pkg argument is optional, can be specified multiple times, and filters what it will actually remove. It then prints, one per line, the packages that were affected.
That sounds good as a standalone feature in downgrade
. However, since we already planned a --noignore
flag in #118, I fear this might lead to some confusion with --unignore
and --noignore
sounding similar but having very different functionalities. But we can fine-tune that when we get to it.
and see if we can get that added to pacman-contrib. Then downgrade could just use it, and this specific feature would end up being provided by that instead:
And this sounds like the best-case scenario, since we add a new pacman
feature for the community and also use that for our own purposes. @pbrisbin do you have any experience with submitting PR's to pacman-contrib
, in terms of how open they are for changes?
But in any case, I do think we have a strong case for it; because pacman already offers the --ignore
flag. So it would only be natural to offer the negation of it as well.
Do you have any experience with submitting PR's to pacman-contrib, in terms of how open they are for changes?
Following up on this question, @pbrisbin any inputs?
Sorry, no experience there. It is an open source project, so it must be possible right?
FWIW, I think the --*ignore
suite of options could work well together:
--ignore
: Add this package to ignores--noignore
: Don't add this package to ignores--unignore
: Remove this package from ignores
Defer to you though.
It is an open source project, so it must be possible right?
Yes, possible. I found their GitLab repository here.
FWIW, I think the --*ignore suite of options could work well together
LGTM as well. We can fine-tune once I create a PR.
I was searching for an --unignore
option for downgrade
today as well. That would be absolutely perfect for me, instead of having to manually edit /etc/pacman.conf
to remove the package(s) from the IgnorePkg list. Sometimes a new version of a package has an issue and downgrade
is a beautiful tool to add it to the IgnorePkg list easily when I need to avoid updating it until the issue is fixed in a new release, but not being able to unignore just as easily is less beautiful.
Is there an update on this discussion?
Thank you for your software and this productive discussion.
@AlexFolland thank you for your comment and kind words.
Unfortunately no updates since the last discussion. I had initially placed this issue on a lower priority compared to the more recent ones due to the complexity involved. But since there is interest, I'll try and get to it sooner.
Based on the quick discussion on the pacman-contrib
mailing list, it seems we are better off developing pacignore
ourselves for now. We could submit a patch upstream at a later point in time.
Some thoughts on developing pacignore
:
-
As mentioned by @pbrisbin,
pacignore
could follow the following syntax:pacignore ls|add|rm [pkg...]
PS: @pbrisbin not sure if we should still name it
pacignore
or perhapsdowngrade-ignore
such that it fits in with our other modular scripts such asdowngrade-select
etc. Also this would signify that it is not an official upstream script but one offered bydowngrade
. We can iron this out later as well. -
For
pacignore ls
, we can just runpacman-conf IgnorePkg
. -
For
pacignore rm|add
, I think this should be fairly straight-forward:- First we get an array of ignored packages by running
pacignore ls
- If the subcommand is
add
, we append a new package to that bash array if it does not exist, otherwise exit 1 - If the subcommand is
rm
, we remove the package from the bash array if it exists, otherwise exit 1 - Now we need to re-write the
IgnorePkg
directive inpacman.conf
. I suggest the following workflow:- Create a new
IgnorePkg
single-line string (in memory i.e. unwritten) with space-separated packages - Remove all lines which contain an uncommented
IgnorePkg
string - Add the new
IgnorePkg
single-line string directly below the[options]
header. The[options]
header should be guaranteed to exist otherwisepacignore ls
in (i) would fail because ofpacman-conf
.
- Create a new
- First we get an array of ignored packages by running
WDYT?
Source: https://wiki.archlinux.org/title/pacman#Skip_package_from_being_upgraded
All sounds good to me.
I don't feel strongly, but I think naming it pacignore
is still good. It indicates it's completely distinct from anything downgrade-related and is just a tool that downgrade-the-script happens to use (but also downgrade-the-project supplies). Less work if/when we move it out of dowgrade-the-project's control. I don't think pacman-the-project owns the "pac" prefix, so I'm not worried about a false sense of officiality, myself. Other options are ignorepkg
, pacman-ignore
, edit-ignorepkg
... π€·
Should we consider making a downgrade Org on GitHub, to hold downgrade/downgrade and downgrade/pacignore repositories?
It seems like overkill, but would also allow you to be a full Admin in the Org and thus have more control over the projects than I can grant when they're personal repositories to me.
Having to use a separate tool does kind of defeat the beauty of unignoring using the same tool that was used to ignore. It limits the discoverability by someone who downgraded and ignored the package using downgrade
.
No, you would still use downgrade
, it would just call the separate tool under the hood.
I don't feel strongly, but I think naming it pacignore is still good.
I don't think pacman-the-project owns the "pac" prefix, so I'm not worried about a false sense of officiality, myself.
Okay, am on board to call it pacignore
. IMO it's also the most catchy and we don't seem to be breaking any rules here.
Should we consider making a downgrade Org on GitHub, to hold downgrade/downgrade and downgrade/pacignore repositories?
I like the idea. It seems like overkill now, but I can see this being useful when downgrade
grows and develops even more features that require further independent repositories such as pacignore
.
I would say let's do it :) We probably need to discuss an org photo, unless you already have some ideas in mind