Arch Linux

I am not opposed to this, but I am not sure it is nice to implement. We would need to store everything, all these messages, and even the scriptlets output, to display them at the end.
So I guess I am happy enough with pacman log on the occasional big installs (this should not be every time ;))

Also I wonder if I didn't already see this request somewhere..

Edit : Found it :  FS#12419 
A very important point that Dan made there and that I totally forgot : it is very useful to have all these information in the context, to know which package they concern.

Edit 2 : I just noticed you put the package in front of each line in your feature request, so forget the previous line.

Strange I didn't find that request while I did a search for install messages... Is that because it's closed?

If this is going to be complicated to implement there's no point to it. But would it be that complicated?

btw, with 'moving' in this case I mean copying...

Shouldn't be that difficult to implement... just some modifications to the way we create pkgbuild would help. Example:

#.install file

#This function will output important messages at the end of installation, such as needed directions which need to be run manually.
post_install_output {
echo You must manually run foo before starting bar so it get properly configured. Avoiding this will make the app crash.
}

#This function will execute an scriptlet needed for the program to run correctly
post_install {
echo Executing needed routine for installation, please wait
exec /usr/bin/moajaja foobar
echo Done
}

post_update {
post_install
}

post_update_output {
post_install_output
}
##End of file

Then of course, we could have for example this when installing

bash $ pacman -S foo bar foobar
pacman installing packages foo, bar, foobar

Downloading
foo 100%
bar 100%
foobar 100%

Installing
foo... Done
bar... Done
Executing needed routine for installation, please wait
Done
foobar... Done

Foo:
Optdepends: ubu (for lyrics support)
Bar:
You must manually run foo before starting bar so it get properly configured. Avoiding this will make the app crash.
Optdepends: cups (for printing)

bash $

PD:

Excuse my terrible example, but I wasn't in the mood to copy exact pacman output for this, hopefully it's understandeable with the idea I had on mind. Guess it's pretty simple.

Where it says Downloading, you can see some output, this comes from the post_install function, as you see, there it wont say anything important, it'll just ask to wait for some program to be executed and then will continue installing programs, after that, when everything is installed then the important output comes. Here pacman will execute the post_install_output function, which is the is the one that has to say the important messages to the user. of course pacman will automatically also tell you the optdepends...

I've never really understood this request. When I have 50-ish messages at the end, how am I going to know what package they are for? You've lost all context from when the things were installing. And if you say you should print (again!) the names of the packages, then what is the point?

Whatever happened to paying attention and/or reading your logs?

Dan:

Read my example again. It names again the package and then shows it's correspondant output.

The idea of this, is that it's usually tricky to read all of the output and sometimes things get lost. Personally, I thinks this "resume" is easier to read, it's simple and it's not confusing as the current method which is WAAAY wicked.

I would summarize this bug with this:

"When you install a bunch of packages it's easy to miss some of the installation notes.
Scrolling back is sometimes impossible and while you could take a look at pacman log every time, it seems a better idea to sum all important install messages up at the end of each installation in stead of in between the numerous text lines."

It is time for a serious example...

Here the pastebin of a large upgrade:
http://pastebin.com/ma15eaf9

Here the sumerised install notes:
glibc: warning: /etc/locale.gen installed as /etc/locale.gen.pacnew
ATTENTION INTERNATIONAL USERS:
Locales are no longer included in the glibc package.
They are generated by /usr/sbin/locale-gen
If you need additional locales, please enable them in /etc/locale.gen and run
/usr/sbin/locale-gen

gutenprint: Please run /usr/sbin/cups-genppdupdate
and restart cups deamon

jre: In order to have java applets support in firefox you should install
libxtst (pacman -S libxtst).

qtmod: Documentation is separated, its called qtmod-doc

kdemod-kdebase-workspace: The plasma backports have been cleaned up, which should
solve most problems like slow startup. However, only the
panel hiding and plasma tooltips are used from now on, which
could cause some problems after the update. The new desktop
containment stuff has been removed because of too much poblems,
sorry for that...

kernel26: If you use the LILO bootloader, you should run 'lilo' before rebooting.
If you use LVM2, Encrypted root or software RAID,
Ensure you enable support in /etc/mkinitcpio.conf .
More information about mkinitcpio setup can be found here:
http://wiki.archlinux.org/index.php/Mkinitcpio

memtest86+: For using memtest86+ please modifiy your bootloaders.

openoffice-base: See http://wiki.archlinux.org/index.php/Openoffice
how to use extensions, e.g. for spell checking
see /opt/openoffice/share/extension/install what
is shipped with this package

p7zip: In order to use p7zip with mc:
Add u7z to /usr/share/mc/extfs/extfs.ini
and add the following to /usr/share/mc/mc.ext:

# regex/\.(7z|7Z)$
# View=%view{ascii} 7za l %f
# Open=%cd %p#u7z

slim: warning: /etc/logrotate.d/slim installed as /etc/logrotate.d/slim.pacnew

I actually spaced that last one to make it more readable, but forgot tabs get lost here...

Maybe most important is the different syntaxes used... cause therefore grepping is more difficult.
I see --> | ==> | >>> | > | ::
When every *important* message for example starts with '*' grepping them would be a lot easier.
Remember pacman log becomes BIG! So it would be nice if you could use a simple grep command.

Are you seriously suggesting to add even more scriptlets functions, just because of this minor issue?
Adding post_install_output / post_ugrade_output sounds like undesired complications.
Also keep in mind that just adding the support of this would not solve anything, all scriptlets would also need to be updated. Good luck with that.

How about this: Collect all the install notes in a temp file and dump it to console when the install finishes.

Why not just dump them to a file so a user can read them at their leisure...

I think that the best solution is to dump the whole pacman output to a file in /tmp (e.g. /tmp/pacman-yyyymmddhhmmss.log).
Motivations:
1) not everything goes to /var/log/pacman.log (e.g. optdepends messages)
2) copying install messages when install ends is awful
3) if I run pacman in a tty, then I switch tty and go back I can miss something if the messages occupy more than one screen so 2) doesn't solve anyway

Note that one could get a full log by running:

# pacman -Su 2>&1 | tee mylog

but at the moment it doens't work very well; it seems that some output is buffered.

Example:
# LANG=C pacman -S python-eyed3
warning: python-eyed3-0.6.17-1 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...

Targets (1): python-eyed3-0.6.17-1

Total Download Size: 0.00 MB
Total Installed Size: 0.48 MB

Proceed with installation? [Y/n]
checking package integrity...
(1/1) checking for file conflicts [#####################] 100%
(1/1) upgrading python-eyed3 [#####################] 100%

# LANG=C pacman -S python-eyed3 2>&1 | tee LOG
warning: python-eyed3-0.6.17-1 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...
Proceed with installation? [Y/n]

Targets (1): python-eyed3-0.6.17-1

Total Download Size: 0.00 MB
Total Installed Size: 0.48 MB

checking package integrity...
checking for file conflicts...
upgrading python-eyed3...

We shove all this in pacman.log these days anyway; does anyone see any reason to keep this issue open? Even implementing this, with a big enough upgrade, you are going to lose a lot of messages off the top of the screen. Reading the log file is really the only way to ensure you see everything.

Unless we also run the install scriptlets at the end, a good portion of the install messages will be wrong when placed at the end. e.g. From my pacman.log:

"Updating font cache..."
"Updating module dependencies. Please wait ..."

Not printing these during the operation would make it look like pacman had frozen. So they need to be printed at the time.

Agree on "Won't Implement".