$ print_scriptlet() { cat /var/lib/pacman/local/$1-*/install}
$ print_scriptlet epiphany
pkgname=epiphany

post_install() {
usr/sbin/gconfpkg --install ${pkgname}

update-desktop-database -q
gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
}

pre_upgrade() {
pre_remove $1
}

post_upgrade() {
post_install $1
}

pre_remove() {
usr/sbin/gconfpkg --uninstall ${pkgname}
}

post_remove() {
update-desktop-database -q
gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
}

that only works for packages which have been _already_ installed on the system ... so IMHO it's only useful if you're going to uninstall something

in case in case you want to see what the scripts will do do on the system _before_ the they've been installed, you've to download the .tar.gz and extract the .INSTALL file which is within it, which is much more inconvenient :(

How on earth would this even be done? It seems like a big hack to me, and just pointing vim at a package tarball and opening it up and reading .INSTALL would be easy enough.

Dan, if you put the problem in this terms, you can even search for package dependencies pointing vim to the depends file ... so why shall we do it using pacman?

The point is that _I_ think it would be very useful to see what the post/pre install scripts will be doing on my system before the package will be installed ... not necessarily every time, obviously, so _I_ think that it would be great to have such an option in pacman!

Pacman, in fact, knows already HOW TO DOWNLOAD the tarball and HOW TO EXTRACT files from it ... it even knows that the .INSTALL file in the tarball doesn't have to be extracted but eventually executed ... so it doesn't appear to me A BIG HACK an option which will eventually just print on the screen its contents.

I don't see what the big deal is, just make the function smarter.

print_scriptlet() { sudo pacman -Sw --noconfirm $1 ; bsdtar -xOf /var/cache/pacman/pkg/$(pacman -Q $1 | sed "s/ /-/")*.pkg.tar.gz .INSTALL }

It is much more convenient to write in sh than to implement in pacman. Even if the different bits are there, they are not made to be used that way, so it would still be a hack somehow.

well,

print_scriptlet() { (cat /var/lib/pacman/local/$1-*/install 2> /dev/null) || (sudo pacman -Sw --noconfirm $1 ; bsdtar -xOf /var/cache/pacman/pkg/$(pacman -Q $1 | sed "s/ /-/")*.pkg.tar.gz .INSTALL) || }

so at least it will also be able to show the data from a package already installed if found and on the repo only if needed.

but now, assuming that we may also be able to get it working without any bug quickly, if we keep it as a shell script it will only be used by me and few other people coming here for their needs.

I just thought that it would have been useful for others too, so I proposed it as a feature request for pacman (quickly available to everybody) but appreciate your help with the shell and in general your promptly response.

Keep up the good work,
pacman and archlinux are great.

Btw, yaourt is a pacman wrapper written in bash, which adds a ton of user-friendly features, imo in the same spirit than this one.
So if yaourt does not have that feature yet, it could be a good idea to request it. And since it is bash, that print_scriptlet function could even help, at least as an example of implementation.
http://bbs.archlinux.org/viewtopic.php?id=25718&p=1
Bugs: http://bugs.archlinux.fr/index.php?tasks=all&project=3

Only just noticed this bug. If someone made a nice script that did this with nice checks (like source pacman.conf for CacheDir) and some additional features (being able to pass the package file), I would have no objection to putting it in pacman-contrib.

hi Allan,

the attached file just works, but will certainly need improvements in the future

thanks!

I just added some useful additions, hope someone (other than me) will enjoy!

here some more additions ... including a version number (and option) for the script

Here is my attempt to improve that script :P
The only thing I am not so happy about is the multiple calls to pacman, but well it should not be a big deal. And it is much more bullet proof now :)

hi Xavier, thanks for helping, there are just two things more I'll be glad to see (I'm not going to do the changes myself to avoid filling the bug's page with unuseful stuff)

1. would you add your name at the top in the copyright line?
2. would you put back the check against the EUID instead of using sudo (which I don't have installed and probably a lot of others because it's in base but not installed by default)

We transformed a one-line script in a 132 lines one!

Looks good to me. I will check it and put it into contrib.