FS#12419 - pacman should output info about .pacnew files at the end

Attached to Project: Pacman
Opened by bughunter2 (bughunter2) - Thursday, 11 December 2008, 23:16 GMT
Last edited by Dan McGee (toofishes) - Monday, 22 December 2008, 18:24 GMT
Task Type Feature Request
Category Output
Status Closed
Assigned To Dan McGee (toofishes)
Architecture All
Severity Very Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Pacman should output messages about .pacnew files after it is done with
updating packages, not meanwhile every package is being updated. The messages
should be collected and displayed at the end, when pacman is done with
everything.

I've discussed this on the #archlinux IRC channel, and I was being told this
feature would be called bloat.
It's not bloat, it's just *moving* a few of pacman's outputted messages to
another place, namely at the end after it's done updating. You could call it a
"summary" about the .pacnew files. This would be nice to have, since then you
don't have to use "yes | pacman -Syu | less" or
"pacman -Syu && updatedb && slocate *.pacnew".

I'm not saying I need this feature, but I find it helpful and I'm sure a lot of
users (especially newcomers) will love this feature.

One might argue that it's not the responsibility of the tool and that it does
not conform to the UNIX philosophy "do one thing and do it well". This isn't
true since in this case, pacman is doing one thing not well, namely being user
friendly. Simply *moving* the messages from the output of pacman to the
end of its output makes it more *friendly* to see what the user needs to do.
It's not bloat, it's just moving some output of a feature that was already
there. If you say it is bloat, then you might as well remove the feature of
telling the user about .pacnew files at all, since that is the real feature.
I'm just giving a suggesting about how to make the existing feature more
*useful*.

Also you can say the user should read everything pacman says anyway, but there
are priorities to what the user should read. For example:
--> It is recommended to use qjackctl as a controlling frontend for the
--> audio server. The extended rights for realtime capabilities can be
--> granted based on groups or a per user base in
--> /etc/security/limits.conf
Thinks like that are relatively unimportant since one might not want to use
qjackctl at all. Thus, updating .pacnew files should be seen as a higher
priority, since important system files might have to be updated. So, it might
be helpful to move the high priority items to the end of pacman's output.
Though, this feature request is merely limited to .pacnew files.

You could say a user should always know what to do, because the user is the
system administrator. But just moving a message is helpful in this case, it's
not trying to make the user more dumb, it's just a reminder.
(And if you do say that the user is responsible for doing everything on their
own and the system should manage nothing on its own, you might as well remove
the automated process of updating the kernel image with mkinitcpio after a
kernel upgrade. Since, after all, the user should do it.)
This task depends upon

Closed by  Dan McGee (toofishes)
Monday, 22 December 2008, 18:24 GMT
Reason for closing:  Won't implement
Additional comments about closing:  See comments. The easiest approach to get similar behavior is to grep pacman.log when pacman terminates for any pac* messages.
Comment by Glenn Matthys (RedShift) - Thursday, 11 December 2008, 23:39 GMT
You know, all pacman output is logged to /var/log/pacman.log... And if we delay all that output to the end, you don't know which package the message belongs to anymore.
Comment by bughunter2 (bughunter2) - Thursday, 11 December 2008, 23:49 GMT
You could write those to the log (invisibly to the user) and also display it at the end. Such a thing should not be a major issue in order to make software more user friendly.
Comment by bughunter2 (bughunter2) - Thursday, 11 December 2008, 23:51 GMT
^ invisibly -> invisible
Comment by Glenn Matthys (RedShift) - Friday, 12 December 2008, 08:34 GMT
You seem to be very keen on that this kind of modification would suddenly make pacman "user friendly". I seriously doubt that. Making software compatible with lazy people doesn't make it user friendly at all. This modification would be counter productive. If you really want your pacman to delay such messages, write a patch and apply it yourself. It would also mean that every package .install output would have to be modified to somehow include a reference to the package, otherwise you'll just get a bunch of "let there be light" without mentioning which switches you have to flick for that. Delaying the output to the end would also mean pacman would suddenly start hanging at "Installing x" (like for example the kernel initcpio creation) with no explanation. Arch Linux isn't focused on newbies anyway. Big -∞ from me. I am going to assign this to the right people, but requesting closing it anyway because I think your idea won't last very long.
Comment by bughunter2 (bughunter2) - Friday, 12 December 2008, 13:37 GMT
No, it just makes it *more* user friendly than it currently is. I'm not saying that after that pacman would be 100% user friendly.
Lazy people have nothing to do with this, since the software is just helpful by notifying you something (and in a manner that is more user friendly than it currently would be).
Technical problems or bad design are a lazy excuse to not make software user friendly.
User friendliness != Lazyiness
Comment by Aaron Griffin (phrakture) - Friday, 12 December 2008, 18:24 GMT
Dan, care to weigh in?
Comment by Dan McGee (toofishes) - Wednesday, 17 December 2008, 05:45 GMT
I'm more of a fan of having pacnew messages in context rather than clumped together, which means seeing the pacnew messages come up near the install lines of hte packages they are associated with. It is really easy to open pacman.log at the end if you missed something and grep around as necessary.

Technically, grouping them would be harder, but that didn't really factor into my decision. Other things worth considering, however- what happens if pacman barfs and you queue messages? Not that it happens often (if ever) anymore, but its something worth considering anytime message queueing comes up.
Comment by bughunter2 (bughunter2) - Wednesday, 17 December 2008, 07:21 GMT
Yeah well it's debatable I guess. Perhaps this could become a configurable thing for the user? I just filed this bug report merely because I see a lot of users miss the .pacnew files (I did too when I started with Arch).
Comment by Glenn Matthys (RedShift) - Wednesday, 17 December 2008, 09:57 GMT
That's because they aren't paying enough attention and that is their own fault. IMO.
Comment by Dan McGee (toofishes) - Wednesday, 17 December 2008, 12:55 GMT
Please try to keep the hostility to a minimum here...

We have quite a few configuration parameters already, and this would be yet another. I'm just not in support of it. We trust that our users actually read program output because we try hard not to spit out unnecessary information, and if they can't be bothered to do that I'm not convinced moving it to the end will suddenly fix the situation.
Comment by Sterling Winter (sterling) - Monday, 22 December 2008, 03:44 GMT
FWIW I've expanded the wiki article on .pac* files and it now lays out several ways to address the "I didn't see that message" problem (lazy users tend not to read the wiki however):

http://wiki.archlinux.org/index.php/Pacnew_and_Pacsave_Files

If the pacman devs could review it and make (or suggest) necessary corrections I'd be grateful.

Loading...