How to bump version but NOT let pkg be upgraded?

MountainX · 2020-12-08 02:36:33

I need to make some improvements to an installer script for a package (EDIT: my own package along with my own local repository). My pkgver is 1.0.r16-1. I think it is best to bump my pkgrel from 1 to 2 when I make these changes. However, for any devices that already have version 1.0.r16-1 installed, these changes are of no benefit and I prefer not to install the newer package in that case. (The package has something to do with connectivity, and it is a pain to install when working on a remote device due to the loss of connection.)

I was thinking about doing something like this:

pre_upgrade() {
  if [[ $(vercmp "$2" "1.0.r16-1") -eq 0 && $(vercmp "$1" "1.0.r16-2") -eq 0  ]]; then
    echo "No update is needed."
    exit 1
  fi
}

Is that a good approach? I don't actually know if it will work since I have not tested it yet. What is the effect of the "exit 1" statement in the pre_upgrade()? Does the entire pacman update abort?

EDIT: this code does not accomplish my goal. It gives the message and error, but then it proceeds with the upgrade anyway.

:: Processing package changes...
no update is needed
error: command failed to execute correctly
(1/N) upgrading package_abc

Is there a way to skip just this specific package update (with the versions matching) while continuing with all other updates?

EDIT 2: I know I could use a command line option for pacman (IgnorePkg=package_abc), but to check & match the versions will require writing a script. If I am going to do that, it seems better to put the code in the installer.

Last edited by MountainX (2020-12-08 03:34:44)

Trilby · 2020-12-08 03:31:40

What package is this? I gather this is just something you are using yourself and not sharing in the AUR, right? If that's the case, there is no actual need to bump the pkgrel. If you explicitly want to ignore the change on most machines, just keep the pkgver and pkgrel the same.

MountainX · 2020-12-08 03:33:39

Trilby wrote:

What package is this? I gather this is just something you are using yourself and not sharing in the AUR, right? If that's the case, there is no actual need to bump the pkgrel. If you explicitly want to ignore the change on most machines, just keep the pkgver and pkgrel the same.

It is just for internal use. It is not on the AUR. However, when I do not bump the version number (pkgrel), the prior version stays in my local repository and when I try to install the package for the first time I get "1.0.r16-1" instead of the one with my improved installer.

Trilby · 2020-12-08 04:25:45

What do you mean it "stays there"? It's not going to replace itself. Rebuild the package and copy it to the repo - you'll overwrite the existing one which will then be used for subsequent installs.

MountainX · 2020-12-08 04:53:24

Trilby wrote:

What do you mean it "stays there"? It's not going to replace itself. Rebuild the package and copy it to the repo - you'll overwrite the existing one which will then be used for subsequent installs.

It is a tedious manual step to manage my local repos that way. I have to remove the package, signing the repo db, then add the new package & signature and sign the db. (Then I have to repeat that at the other copy of my local repo because without a version change, the propagation doesn't seem to work.) I have done it this way in the past and I do not like it. It was error-prone. My experience was that I had to be sure to remove all the old files manually from more than one place.

I would rather bump the version number, if possible. Then all my existing scripts for managing my packages and repos just work. Everything is clearer too because the package actually did change.

drcouzelis · 2020-12-08 15:07:29

This situation is really confusing... Is this package to be used by anyone other than yourself?

I think the best and simplest solution is to just bump the pkgrel from 1 to 2 and have the users (just you?) understand that this can only be installed when they have a good network connection, an opportunity to reboot, or whatever is needed.

If you are worried about the situation where "sure, that's fine for going from pkgrel 1 to 2, but what about when I bump the pkgrel to 3, then 4, then...", then it sounds like you are doing package testing and development on a production server. Instead of doing that, just get it working on one computer, then release the one final good version to your repo.

MountainX wrote:

it is a pain to install when working on a remote device due to the loss of connection

This sounds very strange. It's just installing a package! Are you putting code in a PKGBUILD file that doesn't belong there?

null · 2020-12-08 16:11:28

MountainX wrote:

It is a tedious manual step to manage my local repos that way. I have to remove the package, signing the repo db, then add the new package & signature and sign the db. (Then I have to repeat that at the other copy of my local repo because without a version change, the propagation doesn't seem to work.) I have done it this way in the past and I do not like it. It was error-prone. My experience was that I had to be sure to remove all the old files manually from more than one place.

Just use aurutils?

Last edited by null (2020-12-08 16:12:23)

MountainX · 2020-12-08 19:22:42

null wrote:

Just use aurutils?

I do use aurutils. Have been for a while.

MountainX · 2020-12-08 19:26:14

drcouzelis wrote:

MountainX wrote:
it is a pain to install when working on a remote device due to the loss of connection
This sounds very strange. It's just installing a package! Are you putting code in a PKGBUILD file that doesn't belong there?

It's the package that provides the only connection to the device being updated, and it has security implications.

MountainX · 2020-12-08 20:11:46

What I have gleaned from this thread is that there is apparently no way to make pacman skip the installation of a package based on conditions determined in the pre_upgrade() function. Is that correct and is it the final word?

I don't know anything about the pacman code, but my guess was that using the pre_upgrade() function to skip a listed package is possible... looks like I guessed wrong.

eschwartz · 2020-12-08 20:33:48

The point of an install script is to do things *in addition to* installing the package.

It's never okay to tell pacman internals to remove packages from the transaction list, *after* the transaction started. If you don't want the package to be installed, the time to decide this is before asking pacman to do so. Or by not releasing an update.

It is possible with hooks, which specifically document AbortOnFail, to have PreTransaction hooks that check for certain conditions, then refuse to permit installing *any* packages. But then pacman simply says "error: you cannot update today, go fix your XXXXX".

MountainX · 2020-12-08 20:37:09

eschwartz wrote:

The point of an install script is to do things *in addition to* installing the package.
It's never okay to tell pacman internals to remove packages from the transaction list, *after* the transaction started. If you don't want the package to be installed, the time to decide this is before asking pacman to do so. Or by not releasing an update.
It is possible with hooks, which specifically document AbortOnFail, to have PreTransaction hooks that check for certain conditions, then refuse to permit installing *any* packages. But then pacman simply says "error: you cannot update today, go fix your XXXXX".

Thank you! Great explanation.

Arch Linux

#1 2020-12-08 02:36:33

How to bump version but NOT let pkg be upgraded?

#2 2020-12-08 03:31:40

Re: How to bump version but NOT let pkg be upgraded?

#3 2020-12-08 03:33:39

Re: How to bump version but NOT let pkg be upgraded?

#4 2020-12-08 04:25:45

Re: How to bump version but NOT let pkg be upgraded?

#5 2020-12-08 04:53:24

Re: How to bump version but NOT let pkg be upgraded?

#6 2020-12-08 15:07:29

Re: How to bump version but NOT let pkg be upgraded?

#7 2020-12-08 16:11:28

Re: How to bump version but NOT let pkg be upgraded?

#8 2020-12-08 19:22:42

Re: How to bump version but NOT let pkg be upgraded?

#9 2020-12-08 19:26:14

Re: How to bump version but NOT let pkg be upgraded?

#10 2020-12-08 20:11:46

Re: How to bump version but NOT let pkg be upgraded?

#11 2020-12-08 20:33:48

Re: How to bump version but NOT let pkg be upgraded?

#12 2020-12-08 20:37:09

Re: How to bump version but NOT let pkg be upgraded?

Board footer