FS#6420 - downgrading support

Attached to Project: Pacman
Opened by Roman Kyrylych (Romashka) - Wednesday, 14 February 2007, 22:52 GMT
Last edited by Xavier (shining) - Monday, 19 October 2009, 11:07 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Medium
Priority Normal
Reported Version 3.0.4
Due in Version 3.3.3
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

Details

pacman doesn't have support for downgrading. Yes, it is possible to do as described in http://wiki.archlinux.org/index.php/Downgrade_packages, but it's not a nice solution.

FR #1: support downgrading to versions in cache (will need improved -Sc too)
FR #2: support for replacing newer local versions with older from current/extra (very useful when switching off from testing or unstable).
This task depends upon

Closed by  Xavier (shining)
Monday, 19 October 2009, 11:07 GMT
Reason for closing:  Implemented
Additional comments about closing:  #2 was implemented in 3.3.0 with the new -Suu option
Comment by Aaron Griffin (phrakture) - Monday, 04 June 2007, 21:52 GMT
#1 sounds pretty complicated if you ask me, I don't see how -U /var/cache/pacman/pkg/foo-1XYZ.pkg.tar.gz is not "nice".

#2 sounds easier, and I do think I like it.

Regarding both of these, however, downgrading is an edge case, it is not common behavior. If it _is_ common behavior, we need to look at WHY this is so. We do not want users using old packages, and making it easier to do so gives them that ability (especially newbies).
Comment by Scott H (stonecrest) - Tuesday, 05 June 2007, 03:15 GMT
It seems like the whole xdelta thing could speak to this issue (assuming that you can use xdeltas in reverse). Although I'm not sure how the pre_install(), post_install(), etc., would be handled..
Comment by Xavier (shining) - Thursday, 06 December 2007, 12:49 GMT
I don't like #1 either.
#2 sounds nicer, and it's very useful when switching off from testing indeed (but why unstable?), even if it doesn't have much use outside that particular case. And I don't think users should enable/disable testing all the time.
Comment by Nagy Gabor (combo) - Wednesday, 09 January 2008, 14:21 GMT
This may be a bit off here, but I have a more complicated wish:
Tuned #2:
Earlier ftp.estpak.ee hosted older versions of packages (yes, sometimes packages in extra/current were unusuable and thus I had to downgrade); I found this very useful, so I downloaded and installed (-U) older packages by hand from there.
So it would be nice if multiple versions of packages would be allowed in sync repos [to not to confuse dependency resolving and such things the older packages could be placed in a separate place, such as in the .old subdirectory of the repo; this would be used in case of explicit 'pacman -S package-2.0-1' request only]
This may be a theoretical FR because our mirrors probably syncs their dbs from ftp.al.org not _generate_ them (but this can be changed).

Referring to the testing/extra question: you can specify the repo by '-S extra/foo', pacman should downgrade after confirmation.
Comment by Nagy Gabor (combo) - Wednesday, 09 January 2008, 14:27 GMT
Or if you meant for adding a new switch (the opposite of -u) to -S as a downgrade indicator, such as -d (I know, that this is used now): that is easy to implement -- we already detect downgrades in sync repos and give a warning.

PS: With the notation above -Sud could install all version-not-matching packages.
Comment by Tomas Mudrunka (harvie) - Tuesday, 04 November 2008, 22:10 GMT
hey i miss this feature too! i had the same problem with that crappy apt-get in Debian...
Comment by Tomas Mudrunka (harvie) - Tuesday, 04 November 2008, 22:14 GMT
Aaron Griffin (phrakture): sorry for doublepost... there could be some bug in newer version and for example: latest versions of sane fails with my old scanner, but the older works great...
Comment by xduugu (xduugu) - Monday, 19 October 2009, 10:28 GMT
There is now -Suu in pacman which implements #2. Can this bug be closed or are there plans to think about #1 again?

Loading...