Giters

archlinux-downgrade / downgrade

Downgrade packages in Arch Linux

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Revert on downgrade effects

kostadinnm opened this issue · comments

commented

🚀 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.

commented

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:

  1. Check if the package is defined in IgnorePkg
  2. If it is, remove its definition from IgnorePkg
  3. 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.

commented

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 -
commented

Yes, atreyasha, that was exactly what I mean.
As to what pbrisbin have added, that is more comprehensive than I can imagine.

commented

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.

commented

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?

commented

Sorry, no experience there. It is an open source project, so it must be possible right?

commented

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.

commented

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.

commented

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.

commented

@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.

commented

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:

  1. 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 perhaps downgrade-ignore such that it fits in with our other modular scripts such as downgrade-select etc. Also this would signify that it is not an official upstream script but one offered by downgrade. We can iron this out later as well.

  2. For pacignore ls, we can just run pacman-conf IgnorePkg.

  3. For pacignore rm|add, I think this should be fairly straight-forward:

    1. First we get an array of ignored packages by running pacignore ls
    2. If the subcommand is add, we append a new package to that bash array if it does not exist, otherwise exit 1
    3. If the subcommand is rm, we remove the package from the bash array if it exists, otherwise exit 1
    4. Now we need to re-write the IgnorePkg directive in pacman.conf. I suggest the following workflow:
      1. Create a new IgnorePkg single-line string (in memory i.e. unwritten) with space-separated packages
      2. Remove all lines which contain an uncommented IgnorePkg string
      3. Add the new IgnorePkg single-line string directly below the [options] header. The [options] header should be guaranteed to exist otherwise pacignore ls in (i) would fail because of pacman-conf.

WDYT?

Source: https://wiki.archlinux.org/title/pacman#Skip_package_from_being_upgraded

commented

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... 🤷

commented

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.

commented

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.

commented

No, you would still use downgrade, it would just call the separate tool under the hood.

commented

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