pinentry.pacnew

blacktav · 2018-06-29 07:10:04

When updating pinentry today it said

warning: /usr/bin/pinentry installed as /usr/bin/pinentry.pacnew

There is not much difference in the original & new scripts but wondering why it occurred; I certainly have not been poking at it

amish · 2018-06-29 07:30:13

It has been added to backup() of PKGBUILD in last release. And possibly thats the reason.

As pinentry of old version is different from pinentry of new version.

So pacman thinks that old version is modified one and hence new version is installed as pacnew.

Last edited by amish (2018-06-29 07:32:52)

loqs · 2018-06-29 09:31:40

https://bugs.archlinux.org/task/59159

rebootl · 2018-07-15 14:22:06

The bugreport was closed, so what am I supposed to do here. I don't understand why this was done. In six years of using Arch, I was never supposed to edit files under /usr/bin...

This can't be the right way to do things. (I understand why the pacnew is created. But the thing is it should never happen in the first place.)

amish · 2018-07-15 14:41:17

rebootl wrote:

so what am I supposed to do here.

mv /usr/bin/pinentry.pacnew /usr/bin/pinentry

Unless you had your custom /usr/bin/pinentry

amish · 2018-07-15 14:54:05

rebootl wrote:

This can't be the right way to do things.

May be maintainer could have written a small "post-installation" script.

If $(md5sum usr/bin/pinentry) eq "XXXXXXXX"
then
    mv usr/bin/pinentry.pacnew usr/bin/pinentry
fi

But probably its first time a script from /usr/bin is put in backup() so something new to learn and try to avoid in future.

rebootl · 2018-07-15 19:49:35

Thx for your reply.

Idk, I think what bugged me the most was the tone from the assigned person in the bugreport, while it's clearly unusual to have scripts in the backup array...

There is really no point in doing this. It cannot be right to cause trouble and confusion for _everyone_ in order to solve _one's_ problem.

Even the requester himself suggested to put it in /etc, twice. https://bugs.archlinux.org/task/58979

Jeesh, if people want to override default behaviour systemwide they can even put their scripts in /usr/local/bin. I think it's searched first.

At the very least a notification output during update would've probably avoided all of this.

Thx

Allan · 2018-07-15 23:59:43

rebootl wrote:

Jeesh, if people want to override default behaviour systemwide they can even put their scripts in /usr/local/bin. I think it's searched first.

I'm told you think wrong. Apparently gpg hardcodes the pinentry path into itself at configure time. So any version in /usr/local/bin does not get used. I have not tested this...

eschwartz · 2018-07-16 03:52:52

Allan wrote:

rebootl wrote:
Jeesh, if people want to override default behaviour systemwide they can even put their scripts in /usr/local/bin. I think it's searched first.
I'm told you think wrong. Apparently gpg hardcodes the pinentry path into itself at configure time. So any version in /usr/local/bin does not get used. I have not tested this...

I can confirm this, and clarify that GnuPG hardcodes the pinentry in the same directory as the bindir for the GnuPG installation itself (with a ./configure option to override that with a different hardcoded location).

https://git.gnupg.org/cgi-bin/gitweb.cg … db32#l1086

Arch Linux

#1 2018-06-29 07:10:04

pinentry.pacnew

#2 2018-06-29 07:30:13

Re: pinentry.pacnew

#3 2018-06-29 09:31:40

Re: pinentry.pacnew

#4 2018-07-15 14:22:06

Re: pinentry.pacnew

#5 2018-07-15 14:41:17

Re: pinentry.pacnew

#6 2018-07-15 14:54:05

Re: pinentry.pacnew

#7 2018-07-15 19:49:35

Re: pinentry.pacnew

#8 2018-07-15 23:59:43

Re: pinentry.pacnew

#9 2018-07-16 03:52:52

Re: pinentry.pacnew

Board footer