Package Details: downgrade 9.0.0-1

Git Clone URL: (read-only, click to copy)
Package Base: downgrade
Description: Bash script for downgrading one or more packages to a version in your cache or the A.L.A.
Upstream URL:
Licenses: GPL
Submitter: brisbin33
Maintainer: brisbin33 (atreyasha)
Last Packager: atreyasha
Votes: 580
Popularity: 5.47
First Submitted: 2009-11-12 01:48
Last Updated: 2020-10-29 13:46

Dependencies (2)

Required by (0)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 ... Next › Last »

TrialnError commented on 2014-09-17 18:23

In the "AUR-Wikipage"[0] and "Arch Packaging Standards"[1] they describe what a tarball should contain.
And there were on AUR-General ML some topics on that (over the years)[2][3][4] (I point to posts, where they try to describe the term binary in case of interpreted languages).
And since it's more or less the whole project in there I suppose it's too much.

What would it mean for your PKGBuild? Just minor changes:

One minor notice to your makefile.
Instead of the "sed'ing + makepkg --geninteg" you could use "updpkgsums" (comes with pacman) and is doing the same.

brisbin33 commented on 2014-09-17 15:27


I had not heard that discussion or that it's a best practice to not include sources in the taurball anymore. Do you have a link?

It's easy enough to change things to work the other way if there's a compelling reason to do so.

As a sidenote - tagging releases in a VCS and what does or does not go into the taurball are orthogonal in my mind; I'll always tag releases in git regardless of how I'm packaging things.

TrialnError commented on 2014-09-17 09:20

I'm just wondering
You have a git-repo with tagged releases, still you put everything into the tarball, which should be avoided as far as I know (altough there were enough discussions in case of: "Oh, it's just bash-scripts, so that should be ok").

brisbin33 commented on 2014-06-17 14:38

I don't follow. Root permissions are required to install packages. Downgrade escalates for only this step via sudo or su.

What are you expecting?

barton commented on 2014-06-17 08:12

Seems to run with root permissions from my user account. Anyone else see that?

brisbin33 commented on 2014-05-31 12:26

FYI: if you know the time and package, you can easily get the version out of pacman.log.

neverfox commented on 2014-05-31 06:36

Seriously, @SanskritFritz? The only feedback should come from other package maintainers? So if someone maintained all the packages, the ultimate pinnacle of Arch dedication, they could give feedback to themselves?

neverfox commented on 2014-05-31 06:31

I agree with nonerd. I don't keep that close of a tab on version numbers, but I can determine with pretty decent accuracy when I last had a working package.

nonerd commented on 2014-05-17 15:13

When an application is broken after several system updates (pacman -Syu) you typically know _when_ it was working, but not which library versions you had then.
So without downgrade(r) one browses the A.R.M. and looks at the package timestamps - yes they are there.

Anyway thanks for the package! Maybe I'll have a use case in the future...

brisbin33 commented on 2014-05-17 12:55

> Would be more useful when listing package dates and supporting a --date option.

Sorry, I don't think I'll implement this. I'm not sure the info's available and this tool is meant to stay as simple as possible. If it can be done in an extremely simple way, I would certainly review a PR though.

Also, when you research a problem and decide downgrading is the solution, you'll typically know to what version you have to downgrade. I don't see the usefulness of dates here.