package .install script difference between install and upgrade

skimj · 2018-03-06 17:02:44

I'm building a package and would like to use a package .install script to sync some configuration data. What action defines when either the "_install" and "_upgrade" functions are run? I know this sounds basic, but... Is it determined by the package version or the way pacman is called: `pacman -S` vs. `pacman -Su`?

For example if the package is installed and -S is used subsequently (reinstall or "upgrade") would the _install or _upgrade script run? The wiki documentation PKGBUILD#install] is pretty vague on the specifics. I've seen a few examples that replicate the same commands in each function, like `usr/sbin/update-ca-certificates --fresh` which seems to be the answer, I just want to make sure I understand the mechanics.

Scimmia · 2018-03-06 17:20:55

skimj wrote:

I'm building a package and would like to use a package .install script to sync some configuration data.

Bad idea from the start. Configs are handled by the user, not by update scripts.

skimj · 2018-03-06 17:27:55

Doing some quick experiments with `pacman -U` (not from repo -S), it seems like _install is only called the "very first time" a package is installed and after that a "reinstall" (no change in version) is treated the same as a version upgrade and both cases execute the _upgrade function. Is this correct?

skimj · 2018-03-06 17:37:44

Scimmia wrote:

Bad idea from the start. Configs are handled by the user, not by update scripts.

I consider myself warned
But seriously, is no one using custom/private PKGBUILDs to distribute their own confs to multiple machines? I know there are lots of build automation tools like ansible that could be more "ideal" but in this case those would be way overkill and pacman "feels good".

Regardless of my use, I'd still like to understand when install vs upgrade is executed.

eschwartz · 2018-03-06 19:38:17

It's pretty simple from pacman's perspective. When pacman lists the packages it is affecting as it goes through them, it will say:

:: Processing package changes...
(1/6) upgrading foo
(2/6) downgrading foo2
(3/6) installing foo3
(4/6) removing foo4
(5/6) upgrading foo5
(6/6) upgrading foo6

Those are "upgrade", "install", and "remove", it doesn't matter whether they were caused by pacman -Syu, pacman -S foo, pacman -U /var/cache/pacman/pkg/foo-1.0-1-any.pkg.tar.xz, or any other method.
The only not immediately obvious thing is that a version downgrade qualifies, for the purpose of post_upgrade, as an upgrade.

...

That being said, yes, a PKGBUILD is a terrible way to distribute your configuration to ~/ and you should consider using a dotfiles repository instead.
As for system configuration, several people do indeed distribute their /etc configurations like that, but they do so in the PKGBUILD's package() function and not in a post_install script...
See for example https://github.com/Earnestly/pkgbuilds/ … tem-config

Alternatives include not only ansible and other automation tools, but also simple things like etckeeper for storing /etc itself in a git repository.

Last edited by eschwartz (2018-03-06 19:38:57)

skimj · 2018-03-06 20:42:00

Eschwartz wrote:

It's pretty simple from pacman's perspective. When pacman lists the packages it is affecting as it goes through them, it will say:
:: Processing package changes...
(1/6) upgrading foo
(2/6) downgrading foo2
(3/6) installing foo3
(4/6) removing foo4
(5/6) upgrading foo5
(6/6) upgrading foo6
Those are "upgrade", "install", and "remove", it doesn't matter whether they were caused by pacman -Syu, pacman -S foo, pacman -U /var/cache/pacman/pkg/foo-1.0-1-any.pkg.tar.xz, or any other method.
The only not immediately obvious thing is that a version downgrade qualifies, for the purpose of post_upgrade, as an upgrade.

Thanks for the tip about downgrade, I hadn't thought of that situation. You missed the "reinstall" case. Is this also always an "upgrade"?

...

Eschwartz wrote:

As for system configuration, several people do indeed distribute their /etc configurations like that, but they do so in the PKGBUILD's package() function and not in a post_install script...

Yes, this is what I'm doing. I'm just putting a few things (like prompting for the wifi password) in scripts that I don't want baked into the package.

eschwartz · 2018-03-06 20:47:21

1) Yes, to be more specific *_upgrade is run in the event that the package was installed both before and after the transaction, and *_install when the package used to not be installed but now is installed (and the reverse for *_remove).

2) You're... prompting for passwords in the post_install script, and you think this is easier than running the configuration tool manually afterwards? I'm not even sure pacman allows the tty stdin in the scriptlet shell.

skimj · 2018-03-06 21:17:49

Eschwartz wrote:

2) You're... prompting for passwords in the post_install script, and you think this is easier than running the configuration tool manually afterwards? I'm not even sure pacman allows the tty stdin in the scriptlet shell.

Yes, I find it very difficult to run ansible against a target that's not connected to the network. Despite that, there are lots of times I just want a few basic packages and confs set up at install and then be done with it and an "initialinstall" package works great for this.

I have done some simple prompting in these scriptlets like "enable systemctl unit now? y/n" and that has worked well but maybe this is bad use of these install scripts?

eschwartz · 2018-03-06 21:27:47

Let's just say I don't think this is documented use of the install scripts...

Imagine how this would play out with, say, --noconfirm in a scripted update. And yes, scripted updates can make sense if the person doing them actually looks at the logs... or if you're using makechrootpkg to build packages. https://pkgbuild.com has a script for automatically building nightly snapshots of development packages.

skimj · 2018-03-06 22:25:48

Eschwartz wrote:

Let's just say I don't think this is documented use of the install scripts...

Let's just say that I'm not crazy... I cannot find the PKGBUILD where I'm sure that I was doing some stdin prompting. I just tried it in a very simple test and it is not working there. So I think you're right that this won't work. Best case scenario is that I'm confused with another tool, worst case is that I'm completely loosing it.

Allan · 2018-03-06 22:30:22

I'm fairly sure we now close stdin in during pacman operations...

eschwartz · 2018-03-06 22:36:37

Allan wrote:

I'm fairly sure we now close stdin in during pacman operations...

I thought it might be something like that but didn't get around to looking.

... yep, this was fixed in https://git.archlinux.org/pacman.git/co … 68f0f8d8a0 which means pacman 5.x no longer allows that sort of thing.

Arch Linux

#1 2018-03-06 17:02:44

package .install script difference between install and upgrade

#2 2018-03-06 17:20:55

Re: package .install script difference between install and upgrade

#3 2018-03-06 17:27:55

Re: package .install script difference between install and upgrade

#4 2018-03-06 17:37:44

Re: package .install script difference between install and upgrade

#5 2018-03-06 19:38:17

Re: package .install script difference between install and upgrade

#6 2018-03-06 20:42:00

Re: package .install script difference between install and upgrade

#7 2018-03-06 20:47:21

Re: package .install script difference between install and upgrade

#8 2018-03-06 21:17:49

Re: package .install script difference between install and upgrade

#9 2018-03-06 21:27:47

Re: package .install script difference between install and upgrade

#10 2018-03-06 22:25:48

Re: package .install script difference between install and upgrade

#11 2018-03-06 22:30:22

Re: package .install script difference between install and upgrade

#12 2018-03-06 22:36:37

Re: package .install script difference between install and upgrade

Board footer