7

I'm maintaining a Debian package for which we don't currently support upgrades. This means that upgrading this package will result in a broken installation due to configuration files not being properly tagged.

How can I prevent users from upgrading my package once it is hosted in a debian repo?

I tried with the following solutions:

1. preinst script check

I checked for currently installed versions of the project in the preinst script and exited with an error if found one. This breaks the installation though, since preinst script runs after the uninstallation of the previous version of the package.

2. Conflicts directive in the control file

I added the entry:

Conflicts: project (<< [version]), project (>> [version])

In the debian control file of the project but this doesn't seem to prevent upgrades given that dpkg removes the previous version of the package therefore satisfiying the Conflicts.

3. Package name containing the version

I know this would work for sure but we'd like to avoid this kind of solution.

Please note: we want to solve this from the distribution side, not client-side (i.e. package pinning etc.)

15
  • Can’t you avoid publishing the broken package? Or is the goal to allow from-scratch installation of the new version, while preventing upgrades? Commented Jun 6 at 13:12
  • There are other scripts in a debian package then preinst. I would consider (never had this problem) making prerm of the old package fail; that might stop the upgrade, perhaps you need to combine it with a Conflicts-line in control. Commented Jun 6 at 13:16
  • @Henriksupportsthecommunity how would you go about updating the prerm of the old package, given that it’s already installed? Commented Jun 6 at 13:23
  • 1
    @Henriksupportsthecommunity ah right, so you’d ship a prerm that fails if its first argument is upgrade, and that would prevent future upgrades. Commented Jun 6 at 13:33
  • 1
    1. you can not stop users from upgrading any package on their own system. No matter what you try, someone will find a way to do it anyway (e.g. your prerm script check can easily be defeated in a few seconds with vi). The best you can hope for is to make it more difficult...and (most likely) break their system in your futile attempt to stop them doing whatever they want with their own system. 2. It's their system, you have no say in it. 3. What you want is a really bad idea. Don't do it. Instead, fix your broken package so that it can be upgraded. Commented Jun 7 at 8:46

2 Answers 2

6

This isn’t perfect, but you can configure a repository in such a way that apt won’t consider upgrading packages shipped there by default. To do this, set NotAutomatic: yes in the repository’s Release file; see the repository format description for details.

This will stop package upgrades from happening automatically, but it has two disadvantages:

  • it doesn’t stop users from forcing an upgrade (and ending up with a broken package);
  • it applies to all packages in the repository.
1
  • This is neat and, by the looks of it, would work quite well in our use-case scenario: we just want to avoid the auto-update to break the user installation. If the user forces the installation well... we can't do much about it. I'll take a look whether our repository supports this kind of feature (we're using Sonatype Nexus 3) Commented Jun 6 at 13:41
0

As suggested by @Henriksupportsthecommunity, given that (apparently) our repository doesn't support the NotAutomatic flag, we handled it via a prerm script.

We added the following in the prerm script

# Fail if the first argument is 'upgrade' or 'failed-upgrade'
if [ "$1" == "upgrade" ] || [ "$1" == "failed-upgrade" ]; then
    echo "This package cannot be upgraded. Please uninstall the existing version before installing a new one."
    exit 1
fi

and handled the abort-upgrade event in the postinstall script as follows:

if [ "$1" = "abort-upgrade" ]; then
    echo "postinst called with abort-upgrade: nothing to do."
    exit 0
fi

As documented in: https://wiki.debian.org/MaintainerScripts

dpkg upgrade state machine

This leaves the previous version installed and configured correctly without installing the new one. As noted by other users, this doesn't completely prevent user from forcing an upgrade, but our goal here is just to avoid automatic upgrades to break our installation and this seems to achieve our goal.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.