Arch Linux

From pacman.conf manpage:

NoUpgrade = file …
All files listed with a NoUpgrade directive will never be touched during a package install/upgrade, and the new files will be installed with a .pacnew extension. These files refer to files in the package archive, so do not include the leading slash (the RootDir) when specifying them. Shell-style glob patterns are allowed. It is possible to invert matches by prepending a file with an exclamation mark. Inverted files will result in previously blacklisted files being whitelisted again. Subsequent matches will override previous ones. A leading literal exclamation mark or backslash needs to be escaped.

This is not a packaging bug.

I do not have a "NoUpgrade" directive specified in /etc/pacman.conf but get "warning: /usr/bin/pinentry installed as /usr/bin/pinentry.pacnew".

The PKGBUILD specifically states:

backup=('usr/bin/pinentry')

If the manpage reference was about having "NoUpgrade" set, I also don't have it set nor do any of the systems that I manage and they all have seen this pacnew get created.

The pacnew is expected, everyone should have it. The same update that added the backup file, changed the script contents by adding a newline, thus forcing it to manifest as a pacnew for all users.

For clarity, this could have been handled better in packaging then?
Perhaps as two separate updates?

I'm guessing (I'm not a backups expert) that it didn't matter, as once the script is added to the backups the next time it changes (whether pkgver or pkgrel) it would generate the pacnew. New installs after this version wouldn't get a pacnew and won't if the user doesn't edit the file. I also don't know, without some looking into it, if you don't replace your "/usr/bin/pinentry" with "/usr/bin/pinentry.pacnew" whether you will get new versions of the script or if those will keep getting dumped into pacnew files and we'd be stuck with the pinentry from this upgrade (again, without replacing with the pacnew)? I will admit I don't even let anything try and use the autodetect pinentry script and have things configured to call the executable I want.

It looks like this stems from [0]:
1. It seems like the needs of the few will now spawn this warning for everyone for a while
2. Maybe, per the ticket, if pinentry (the arch supplied script at least) were a "arch-project" someone could spend the time to engineer a etc-based solution (I know, it's a volunteer/not infinite free-time set of people)

[0] https://bugs.archlinux.org/task/58979

P.S. I'd be interested to know how many backups exist of things in "/usr/bin/", I'm guessing (hoping) not many

It seems like if the backup of pinentry is going to stick around and if this isn't newsworthy this should be resolved as wontfix

> I'm guessing (I'm not a backups expert) that it didn't matter, as once the script is added to the backups the next time it changes (whether pkgver or pkgrel) it would generate the pacnew.

Of course it mattered. It is a backup file, and backup files become pacnew files *when pacman thinks they've been edited*.

And pacman *only* thinks they've been edited, when 1) they actually were edited, or 2) the maintainer sneaks in a modification to the file in the same pacman transaction with which it became a backup file.

If the file had not been changed in that exact update, it would not be a pacnew.

> I also don't know, without some looking into it, if you don't replace your "/usr/bin/pinentry" with "/usr/bin/pinentry.pacnew" whether you will get new versions of the script or if those will keep getting dumped into pacnew files and we'd be stuck with the pinentry from this upgrade

It's a backup file, by definition since pacman thinks you've edited it yourself it will never give you a new version but just create pacnew files until you merge it by hand.

...

IMHO this should never have been a backup file, because that's not expected behavior for /usr/bin, and no, nothing else to my knowledge does this, and no, this is not newsworthy as nothing even happened. The script still works, the pacnew tells you like all pacnew files, and it's hardly worthy of "onoes, everyone panic and alert the frontpage news because anyone who doesn't get official frontpage news guidance on what to do will end up in trouble".

It's a *minor* bug, but we don't have frontpage news for the other almost 60,000 bugs in Arch Linux history, now do we?

ls /usr/bin/ | wc -l
3282

ls | grep pacnew | wc -l
1

Maybe not news, but it's certainly not nominal.

> It's a backup file, by definition since pacman thinks you've edited it yourself it will never give you a new version but just create pacnew files until you merge it by hand.

I believe this answers my main question which is that you'd have to merge by hand which means you are stuck with a specific pinentry script until you do this (and in this case even if you never edited it you now have that single script pinned to a specific time-in-point)

in addition to last comment: unless the backup for the script is removed from the PKGBUILD

Why are we having this conversation? Pacman spits out pacnew files in situations that warrant it. That's all there is to it. If you don't like pacnew files then don't use pacman...

I don't think anyone is complaining about pacman functionality, rather the unique event of there being a .pacnew now in /usr/bin.

This is nice though, wouldn't feel like arch if there wasn't the edgy "go to another distro" whenever you submit a bug request.

I don't see why you cannot install this instead (sources ~/.config/pinentry /etc/default/pinentry).

Very simple, infinitely flexible, does not make /usr/bin "ugly" by adding backup files willy-nilly.

Also, there's still the issue where you created a backup file in the same update that modified it, thus *forcing* it to be a pacnew for people who did not in fact edit it and have no interest in doing so.

Another reason for reopen is that this is taking place on everyone systems. So anyone who has pinentry install prior to this update will now have a frozen version of pinentry on their system unless they remove and move the packnew. This is affecting _everyone_ who has this package.

So what. The purpose of the new script is to be customizable due to the request of multiple users. Current upgraded systems, with the pacnew file merged or left alone, work. So there's really nothing to do. I'm not going to release a new package with `rm /usr/bin/*.pacnew` in it just to appease your sense of aesthetics. If you reopen this bug again I'll just ignore whatever further comments are posted. Cheers.