[pacman-dev] [PATCH 1/2] Combine add and removal package list display
There was no real reason for these to be done separately.
Signed-off-by: Dan McGee
Pacman did a great job of having almost (but not quite) duplicate code
paths through the sync and upgrade code. We can use the same logic in
both upgrade in sync once the targets are resolved, so extract a
function and delete a bunch of code.
Signed-off-by: Dan McGee
On 07/22/2011 07:19 PM, Dan McGee wrote:
There was no real reason for these to be done separately.
Signed-off-by: Dan McGee
--- A bit of WIP here. Try it out to see what it does, but it addresses Allan's issue with upgrade size being all whacky when replaces are involved, among other things. http://paste.pocoo.org/show/444372/ for some example output with VerbosePkgLists on, http://paste.pocoo.org/show/444368/ with them off. Not sure what to do with the corny '[removal]' tag bit though.
Notes: * The size column is now net changed size per package, so only new packages or totally removed packages will usually have big values (wireshark-cli is buggy in the package itself, as noticed by Dave and I).
I'm not sure I agree with this. During a typical 'pacman -Syu', the net changed size will be ~0.00 MiB for nearly all packages, making the column more or less useless for the most commonly used operation. Unfortunately, I don't have an ideal solution. Currently, the size column displays installed size for removal lists and and package size for install / upgrade lists. I can think of two issues with this: 1) the column header is always 'Size' and it isn't clear enough about what's actually being displayed; and 2) displayed different things in the same column might be confusing/misleading; of course it gets much worse if removal and sync targets are shown in the same list. On the other hand, it feels correct to display sizes like this. During sync operations I want to know about package sizes, and when removing packages I want to know how much disk space is regained. It's also easy to pick out the largest packages during a large -Syu at a glance. The only other option I can think of with a merged removal / sync list is install size, which might be worth a try (even though I believe I'd prefer seeing download size for -S targets). tl;dr - in my opinion we should either stick to the old display with separate removal and sync lists (and fix the column header), or display install size in a merged list. P.S.: It might also be nice to keep the removal / sync target count instead of only displayed a total target count.
* Packages are now always sorted in alpha order, rather than the half-sorted, dep resolved mess we had before. * -R ops will show the same format as -U, even though the new version column will now always be blank. I think the consistency win is worth it. They will also always show the '[removal]' tag bit, so suggestions for that are welcome. * Yes, you get 4 different totals now on -S operations, but since the damn package list is so long anyway, who cares.
All of this sounds good to me.
On Wed, Jul 27, 2011 at 12:12 PM, Jakob Gruber
On 07/22/2011 07:19 PM, Dan McGee wrote:
* The size column is now net changed size per package, so only new packages or totally removed packages will usually have big values (wireshark-cli is buggy in the package itself, as noticed by Dave and I).
I'm not sure I agree with this. During a typical 'pacman -Syu', the net changed size will be ~0.00 MiB for nearly all packages, making the column more or less useless for the most commonly used operation.
A "competing" product does this (trimmed for size): $ sudo yum update ... Package Arch Version Repository Size Updating: kernel-headers i386 2.6.18-238.19.1.el5 updates 1.1 M Transaction Summary Install 0 Package(s) Upgrade 1 Package(s) Total download size: 1.1 M $ sudo yum remove kernel-headers ... Package Arch Version Repository Size Removing: kernel-headers i386 2.6.18-238.19.1.el5 installed 2.2 M Removing for dependencies: gcc i386 4.1.2-50.el5 installed 9.6 M gcc-c++ i386 4.1.2-50.el5 installed 6.5 M glibc-devel i386 2.5-58.el5_6.4 installed 4.9 M glibc-headers i386 2.5-58.el5_6.4 installed 2.0 M Transaction Summary Remove 5 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s) So we do have the size mismatch there as well. Not sure what it does if you are installing an RPM directly.
Unfortunately, I don't have an ideal solution.
Currently, the size column displays installed size for removal lists and and package size for install / upgrade lists. I can think of two issues with this:
1) the column header is always 'Size' and it isn't clear enough about what's actually being displayed; and 2) displayed different things in the same column might be confusing/misleading; of course it gets much worse if removal and sync targets are shown in the same list.
On the other hand, it feels correct to display sizes like this. During sync operations I want to know about package sizes, and when removing packages I want to know how much disk space is regained. It's also easy to pick out the largest packages during a large -Syu at a glance.
The only other option I can think of with a merged removal / sync list is install size, which might be worth a try (even though I believe I'd prefer seeing download size for -S targets).
tl;dr - in my opinion we should either stick to the old display with separate removal and sync lists (and fix the column header), or display install size in a merged list.
P.S.: It might also be nice to keep the removal / sync target count instead of only displayed a total target count. Patches welcome; I could see these being added to the size display at
Anyone else? I'm still not sure what is right here, but I'm leaning toward a tad more explicit but still totally whacky: sync- show "Download Size", show 0.00/-0.00/blank for to-be-removed packages remove- show "Installed Size", all will be negative upgrade- show "Installed Size", all will be positive, unless inducing a removal of a different named package (do we even do this right?), then that one will show negative installed size the bottom. -Dan
On 07/29/2011 10:41 PM, Dan McGee wrote:
On Wed, Jul 27, 2011 at 12:12 PM, Jakob Gruber
wrote: On 07/22/2011 07:19 PM, Dan McGee wrote:
* The size column is now net changed size per package, so only new packages or totally removed packages will usually have big values (wireshark-cli is buggy in the package itself, as noticed by Dave and I). I'm not sure I agree with this. During a typical 'pacman -Syu', the net changed size will be ~0.00 MiB for nearly all packages, making the column more or less useless for the most commonly used operation. A "competing" product does this (trimmed for size):
$ sudo yum update ... Package Arch Version Repository Size Updating: kernel-headers i386 2.6.18-238.19.1.el5 updates 1.1 M
Transaction Summary Install 0 Package(s) Upgrade 1 Package(s) Total download size: 1.1 M
$ sudo yum remove kernel-headers ... Package Arch Version Repository Size Removing: kernel-headers i386 2.6.18-238.19.1.el5 installed 2.2 M Removing for dependencies: gcc i386 4.1.2-50.el5 installed 9.6 M gcc-c++ i386 4.1.2-50.el5 installed 6.5 M glibc-devel i386 2.5-58.el5_6.4 installed 4.9 M glibc-headers i386 2.5-58.el5_6.4 installed 2.0 M
Transaction Summary Remove 5 Package(s) Reinstall 0 Package(s) Downgrade 0 Package(s)
So we do have the size mismatch there as well. Not sure what it does if you are installing an RPM directly.
Unfortunately, I don't have an ideal solution.
Currently, the size column displays installed size for removal lists and and package size for install / upgrade lists. I can think of two issues with this:
1) the column header is always 'Size' and it isn't clear enough about what's actually being displayed; and 2) displayed different things in the same column might be confusing/misleading; of course it gets much worse if removal and sync targets are shown in the same list.
On the other hand, it feels correct to display sizes like this. During sync operations I want to know about package sizes, and when removing packages I want to know how much disk space is regained. It's also easy to pick out the largest packages during a large -Syu at a glance.
The only other option I can think of with a merged removal / sync list is install size, which might be worth a try (even though I believe I'd prefer seeing download size for -S targets). Anyone else? I'm still not sure what is right here, but I'm leaning toward a tad more explicit but still totally whacky: sync- show "Download Size", show 0.00/-0.00/blank for to-be-removed packages remove- show "Installed Size", all will be negative upgrade- show "Installed Size", all will be positive, unless inducing a removal of a different named package (do we even do this right?), then that one will show negative installed size
After some more thought, I'd propose keeping the removal and install lists separate but with a single common summary section. Even when ignoring size inconsistencies, mixing both operations in a single list seems a little hard to read and confusing. A quick mockup: http://pastebin.com/EyVSZ2Zq Another alternative, this time keeping the single list to save a few lines of vertical space but explicitly marking removal/install targets and keeping all removal targets before install targets : http://pastebin.com/QKkWVNsJ What do you think?
On 23/07/11 03:19, Dan McGee wrote:
There was no real reason for these to be done separately.
Signed-off-by: Dan McGee
--- A bit of WIP here. Try it out to see what it does, but it addresses Allan's issue with upgrade size being all whacky when replaces are involved, among other things. http://paste.pocoo.org/show/444372/ for some example output with VerbosePkgLists on, http://paste.pocoo.org/show/444368/ with them off. Not sure what to do with the corny '[removal]' tag bit though.
Notes: * The size column is now net changed size per package, so only new packages or totally removed packages will usually have big values (wireshark-cli is buggy in the package itself, as noticed by Dave and I). * Packages are now always sorted in alpha order, rather than the half-sorted, dep resolved mess we had before.
I am not sure I like this... Currently, "pacman -S foo" will always show "foo" as the last target. I find that makes it clear that the rest of the packages are the needed dependencies. With this patch, "foo" can end up anywhere in the package listing. For a package with lots of dependencies, it becomes difficult to see that "foo" is even being installed at a quick glance.
* -R ops will show the same format as -U, even though the new version column will now always be blank. I think the consistency win is worth it. They will also always show the '[removal]' tag bit, so suggestions for that are welcome. * Yes, you get 4 different totals now on -S operations, but since the damn package list is so long anyway, who cares.
Feedback/thoughts definitely welcome. I'll improve the commit message too before any final version goes live.
-Dan
On Fri, Jul 29, 2011 at 1:09 AM, Allan McRae
On 23/07/11 03:19, Dan McGee wrote:
* Packages are now always sorted in alpha order, rather than the half-sorted, dep resolved mess we had before.
I am not sure I like this... Currently, "pacman -S foo" will always show "foo" as the last target. I find that makes it clear that the rest of the packages are the needed dependencies.
With this patch, "foo" can end up anywhere in the package listing. For a package with lots of dependencies, it becomes difficult to see that "foo" is even being installed at a quick glance.
How about a slight tweak, as I just hated the old seemingly random order. We'll do pulled package alpha-ordered, followed by explict alpha-ordered. This still makes my main beef, the -Syu case, print how I want while solving your problem as well.
On 30/07/11 05:37, Dan McGee wrote:
On Fri, Jul 29, 2011 at 1:09 AM, Allan McRae
wrote: On 23/07/11 03:19, Dan McGee wrote:
* Packages are now always sorted in alpha order, rather than the half-sorted, dep resolved mess we had before.
I am not sure I like this... Currently, "pacman -S foo" will always show "foo" as the last target. I find that makes it clear that the rest of the packages are the needed dependencies.
With this patch, "foo" can end up anywhere in the package listing. For a package with lots of dependencies, it becomes difficult to see that "foo" is even being installed at a quick glance.
How about a slight tweak, as I just hated the old seemingly random order. We'll do pulled package alpha-ordered, followed by explict alpha-ordered. This still makes my main beef, the -Syu case, print how I want while solving your problem as well.
Agreed. That would be fine to me. Allan
participants (4)
-
Allan McRae
-
Dan McGee
-
Dan McGee
-
Jakob Gruber