FS#15772 - Show (or have a option to show) What version of a package you're upgrading from -> to

Attached to Project: Pacman
Opened by JD (jdhore) - Monday, 03 August 2009, 16:57 GMT
Last edited by Dan McGee (toofishes) - Wednesday, 31 August 2011, 13:16 GMT
Task Type Feature Request
Category Output
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 3.2.2
Due in Version 4.0.0
Due Date Undecided
Percent Complete 100%
Votes 10
Private No

Details

I believe it would be a nice feature for Pacman to be able to show what version you're upgrading a package from -> to. It seems like a pretty good idea because sometimes you want to hold back a package if it's a new major kernel version for 1 or 2 bug fix releases or you're upgrading a package that had a major version bump and you want to make sure you update your config file or whatnot.

The output for this could be something simple such as:

Targets (3): kernel26 2.6.30.2-1 -> 2.6.30.4-1, mlocate 0.22-1 -> 0.22-2, deluge 1.1.9 -> 1.2.0
This task depends upon

Closed by  Dan McGee (toofishes)
Wednesday, 31 August 2011, 13:16 GMT
Reason for closing:  Implemented
Additional comments about closing:  VerbosePkgLists, commit e95be3379a
Comment by Allan McRae (Allan) - Tuesday, 04 August 2009, 04:20 GMT
I seem to recall someone submitting a patch for something this in the past but I can not seem to find it...
Comment by Xavier (shining) - Friday, 07 August 2009, 09:07 GMT
http://www.archlinux.org/pipermail/pacman-dev/2007-November/004629.html
the discussion in that thread led to the following patch :
http://www.archlinux.org/pipermail/pacman-dev/2007-November/004660.html
which was re-submitted here :
http://www.archlinux.org/pipermail/pacman-dev/2008-March/005893.html

but it was not merged because :
* if we keep the current output, its +140 lines of code just for an alternative one, and then we have to maintain the code for both
* if we don't, this one might be too verbose and too long (one line per targets), but that might be debatable

I actually find this column output quite cool
Comment by JD (jdhore) - Friday, 07 August 2009, 09:25 GMT
I'd almost say that for "column-style output", something more like the output of Yaourt (excuse the colour if it shows up in this paste):

testing/ruby 1.8.7_p174-1 -> 1.9.1_p129-2
testing/vi 7.2.65-1 -> 050325-1
testing/vim 7.2.65-1.1 -> 7.2.234-1

or for ShowSize included as well

testing/ruby 1.8.7_p174-1 -> 1.9.1_p129-2 [2.49 MB]
testing/vi 7.2.65-1 -> 050325-1 [8.16 MB]

It seems to be a bit cleaner and gets all the necessary information across just as well (i'd say).
Comment by Xavier (shining) - Friday, 07 August 2009, 09:36 GMT
I don't know if its cleaner, but for sure it takes less width and is easier to code.
however the height is exactly the same, which is mostly what Dan was criticizing (having to scrollback).
and I still find the real column output cleaner.

but well, maybe the ShowOldVersion, with yaourt-like output, would have more chances to get in.
Comment by Karol Błażewicz (karol) - Wednesday, 23 June 2010, 23:07 GMT
Status?
I already get similar output (w/o the size) but only for the packages I'm not interested in upgrading :-)

:: Starting full system upgrade...
warning: intel-dri: ignoring package upgrade (7.5.1-2 => 7.8.2-1)
warning: libdrm: ignoring package upgrade (2.4.19-1 => 2.4.21-1)
warning: libgl: ignoring package upgrade (7.5.1-2 => 7.8.2-1)
warning: xf86-input-evdev: ignoring package upgrade (2.2.5-1 => 2.4.0-1)
warning: xf86-input-keyboard: ignoring package upgrade (1.3.2-2 => 1.4.0-2)
warning: xf86-input-mouse: ignoring package upgrade (1.4.0-2 => 1.5.0-2)
warning: xf86-video-vesa: ignoring package upgrade (2.2.0-1 => 2.3.0-2)
warning: xorg-server: ignoring package upgrade (1.6.3.901-1 => 1.8.1.902-1)
warning: xorg-server-utils: ignoring package upgrade (7.4-7 => 7.5-4)
resolving dependencies...
looking for inter-conflicts...
Comment by Dan McGee (toofishes) - Thursday, 20 January 2011, 20:50 GMT
I might backpedal on this a bit; the output in the March 2008 patch isn't too bad.
Comment by Xavier (shining) - Thursday, 20 January 2011, 21:45 GMT
Good news ! And would we keep it as a separate option / alternative output ?
I could look into rebasing that patch if needed.
Comment by Karol Błażewicz (karol) - Wednesday, 31 August 2011, 02:40 GMT
Status?

Loading...