Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#28716 - Improve 'pacman -Sy' output for signed databases

Attached to Project: Pacman
Opened by Karol Błażewicz (karol) - Wednesday, 29 February 2012, 16:25 GMT
Last edited by Allan McRae (Allan) - Wednesday, 29 February 2012, 20:36 GMT
Task Type Bug Report
Category Output
Status Closed
Assigned To Dan McGee (toofishes)
Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version 4.0.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

$ pacman -Sy
:: Synchronizing package databases...
testing 96,2 KiB 326K/s 00:00 [###########################] 100%
community-testing 2,1 KiB 1877K/s 00:00 [###########################] 100%
core 105,2 KiB 347K/s 00:00 [###########################] 100%
extra 1391,3 KiB 675K/s 00:02 [###########################] 100%
community 1538,6 KiB 679K/s 00:02 [###########################] 100%
xyne-any 6,0 KiB 28,3K/s 00:00 [###########################] 100%
xyne-any.sig 287,0 B 272B/s 00:01 [###########################] 100%

I think the 'xyne-any.sig' line should go.


I'm using pacman 4.0.2-1.
This task depends upon

Closed by  Allan McRae (Allan)
Wednesday, 29 February 2012, 20:36 GMT
Reason for closing:  Won't implement
Comment by Dan McGee (toofishes) - Wednesday, 29 February 2012, 16:31 GMT
I personally don't think it should go anywhere except stay right where it is.
Comment by Dave Reisner (falconindy) - Wednesday, 29 February 2012, 16:56 GMT
You present a convincing argument, but I'm in favor of keeping this:

- pacman is very much transparent wherever it can be. hiding random downloads goes against this.
- it makes any network latency on this particular download more obvious. A random delay between two repo downloads would just result in stupid bug reports explaining why we thought it was valuable to remove this output. rest assured that while im very much aware of why this single line needs to be sent to the big bit bucket in the sky, i'd assign these bug reports to you for a detailed explanation.
- If the database is later shown as corrupted or invalid and you didn't see such a download, this will be confusing (cue more stupid bug reports).

Feel free to convince me otherwise.

Comment by Karol Błażewicz (karol) - Wednesday, 29 February 2012, 18:47 GMT
It can be moved to '--debug' output, but _you_ are going to be doing the debugging, not me, so I'm fine if you prefer the way it is now.

I guess package signing and database signing is different enough to warrant different approaches:
http://allanmcrae.com/2011/08/pacman-package-signing-3-pacman/
"Beyond that, the checking of PGP signatures occurs during the usual package integrity check stage so will go largely unnoticed unless something goes wrong."
Comment by Allan McRae (Allan) - Wednesday, 29 February 2012, 20:30 GMT
I am -1 on removing this information. And note it is treated exactly the same as packages when they need to download a signature too...

> pacman -U file:///home/allan/web/allanbrokeit/i686/patch-2.6.1.136-1-i686.pkg.tar.xz
patch-2.6.1.136-1-i686 73.8 KiB 72.1M/s 00:00 [######################] 100%
patch-2.6.1.136-1-i... 287.0 B 2.95K/s 00:00 [######################] 100%
loading packages...

Loading...