Home / ubuntu / Questions / 1512137
Accepted
Dimitris Sfounis
Asked: 2024-04-29 15:39:59 +0800 CST

What happens to apt-tracked packages if I upgrade one manually?

  • 772

I'm on Ubuntu server 22.04 (Jammy).

I'm still a bit of an Ubuntu newbie and I wanted to apt upgrade a package that I have previously installed via apt and the relevant PPA. Turns out I can't, apt can't see the latest version. The reason is that the team behind the PPA failed some builds for the latest version, and apt, logically, thinks I have the latest version since the newer version has failed builds.

The update is pretty important so instead, I wanted to manually install/upgrade the package via the project Github's provided binary. By that, I mean downloading a .tar.gz provided by the project team.

What happens to the package afterwards? Will apt keep tracking a separate version? Will apt refuse to update something that I upgraded manually? Will I shoot myself in the foot and end up with two instances of the same package?

Any info would be appreciated.

apt

1 Answers

  1. Best Answer

    You need to think in terms of a package manager. Package manager has local database that tracks packages, versions and their files. So the only way for it to see the "upgrade" is if you increment in the database the version. Which you may do without changing any of the package content at all, in which case you would kind of "fake" the upgrade, because the package files are still older ones.

    Judging by you mentioning tar.gz file you probably wanted to compile the package from source and overwrite binary files with the ones you built. In that case it will work for a while, but then an update will overwrite the files. Worse yet, if you run a ninja/make install rather than just copy a few file, you may end up with untracked files in your system, which is another can of worms.

    With that said, as long as you have no trouble compiling the software from source (which I assume you haven't since you mention working with tar.gz), making a .deb package of it is very simple. Basically, you:

    1. Create a control file the describes package name, version and anything you'd also want. Don't forget to put the newer version there so that package manager knows not to update the package till even newer version appeared in the remote repo/PPA.
    2. Execute a ninja/make install with DESTDIR being overwritten to the absolute path to the dir where you're going to assemble a package
    3. Call a fakeroot dpkg-deb --build "/foo/bar/package-dir" my-cool-pkg.deb to assemble a my-cool-pkg.deb file

    Then you call a sudo apt install ./my-cool-pkg.deb to install it.

    NOTE: do not use root/sudo to assemble package. If you need it you're doing something wrong. You only need it to install the package afterwards.

    Example: here's a script I'm using to create a git-version of the rr utilities, a framework that allows to record process execution to later replay it in gdb:

    #!/bin/bash
# NOTE: make sure the rr build is configured with --prefix=/usr/. It is
# important, so libraries upon installation end up in correct locations.
set -e

if [ "$#" -ne 1 ]; then
    echo "Wrong number of parameters.
Usage: $(basename $0) build_dir"
    exit 1
fi

BUILD_ROOT=$(readlink -f $1)
PKG_DIR="$BUILD_ROOT"/deb
PACKAGE_VERSION="5.7.0~$(git rev-parse HEAD)"
mkdir -p $PKG_DIR/DEBIAN/
cat > $PKG_DIR/DEBIAN/control <<- END_OF_TEXT
PACKAGE: rr-git
Version: $PACKAGE_VERSION
Architecture: amd64
Maintainer: Mystique Packager
Description: application execution recorder, player and debugger
Depends: libcapnp-0.7.0
Conflicts: rr
Provides:  rr
Homepage: https://github.com/rr-debugger/rr
END_OF_TEXT

cd "$BUILD_ROOT"
DESTDIR="$PKG_DIR" ninja install

# Work around a bug that rr doesn't find lib when installed to standard location.
# Should be fixed in rr actually.
mv "$PKG_DIR"/usr/lib/x86_64-linux-gnu/rr "$PKG_DIR"/usr/lib/
rmdir "$PKG_DIR"/usr/lib/x86_64-linux-gnu

fakeroot dpkg-deb --build "$PKG_DIR" rr_$PACKAGE_VERSION.deb

    You can use this script as a basis to create a deb package for whatever it is you want. You can remove most of the fields in the control file there, because you'll likely only need the PACKAGE and Version fields, and perhaps a Depends if you want.

    • 2