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#14161 - Add a "Maintainer" field to the output of "pacman -Si"

Attached to Project: Pacman
Opened by Xyne (Xyne) - Thursday, 09 April 2009, 18:12 GMT
Last edited by Eric Belanger (Snowman) - Thursday, 09 April 2009, 23:21 GMT
Task Type Feature Request
Category Output
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 3.2.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

The output of "pacman -Si <pkg>" currently shows the "Packager" but this person is often not the current maintainer. It would be much more useful to include the current maintainer so the user would know whom to contact about updating the package. Contacting the packager (which seems logical as the packager's email is the only one given) often results in a "why are you bothering me about this?" reply.

Adding such a field when there's already a similar one for the packager makes more sense than expecting the user to track down the current maintainer through the svn/cvs/aur web interfaces.


Xyne
This task depends upon

Closed by  Eric Belanger (Snowman)
Thursday, 09 April 2009, 23:21 GMT
Reason for closing:  Won't implement
Comment by Eric Belanger (Snowman) - Thursday, 09 April 2009, 19:54 GMT
That won't help because none of the devs change the Maintainer tag when they orphan/adopt a package. You'll still get the same result: "I orphaned this several months ago/ Someone else maintian it now. Why are you bothering me about this?". In this case, the Packager might be the better option.

Also the Maintainer tag is currently a simple comment which is being disregarded. So we'll need to change this so it gets included in the package metadata. In that case, the package will need to be rebuilt when there is a maintainer change. No dev will bother to do this (I think users with limited bandwith/speed won't like it either). So the maintainer info in the package will be out-of-date -> same problem as before.

I think the best/easiest way to know the maintainer is through the web interface.
Comment by Xyne (Xyne) - Thursday, 09 April 2009, 22:57 GMT
I think you're right. I'll request closure.

Loading...