What happens to self-built packages when I `apt dist-upgrade`?

Question

I installed some self-built deb packages (PAM) with

sudo dpkg --force-all -i /opt/bzr/build-area/*.deb

tree is:

/opt/bzr/build-area 
.
├── libpam0g_1.1.8-3ubuntu1_amd64.deb
├── libpam0g-dev_1.1.8-3ubuntu1_amd64.deb
├── libpam-cracklib_1.1.8-3ubuntu1_amd64.deb
├── libpam-doc_1.1.8-3ubuntu1_all.deb
├── libpam-modules_1.1.8-3ubuntu1_amd64.deb
├── libpam-modules-bin_1.1.8-3ubuntu1_amd64.deb
├── libpam-runtime_1.1.8-3ubuntu1_all.deb
├── pam_1.1.8-3ubuntu1_amd64.build
├── pam_1.1.8-3ubuntu1_amd64.changes
├── pam_1.1.8-3ubuntu1.diff.gz
├── pam_1.1.8-3ubuntu1.dsc
└── pam_1.1.8.orig.tar.gz

1. Important: What happens when a new official Ubuntu PAM version is released and I run apt dist-upgrade -y? Will it overwrite my own packages?

2. Optional: Do I need --force-all in dpkg -i?

3. Optional: https://code.launchpad.net/~ubuntu-core-dev/pam/ubuntu looks like a "dev branch" to me? Does a "stable branch" exist? How to get it with bzr?

Related to: https://unix.stackexchange.com/a/382363/239596

Answer 1

1. Yes, they will, if they use a higher version number than your packages, unless you adjust your pin priorities appropriately (or hold the packages, as pointed out by cas). Note that the repositories’ packages are liable to overwrite yours if you use the same version number, so you should really increment your version when you rebuild locally (typically “1.1.8-3ubuntu1.1”).

2. No, and you should avoid it unless absolutely necessary. If you think it’s necessary, there’s probably something wrong with your packages and you should fix that instead.

3. That code repository hasn’t been updated since 2014, so I doubt it’s an active development repository. You can see the various pam branches on Launchpad, and clone them using for example bzr branch lp:ubuntu/vivid/pam.

The way I go about dealing with this type of situation is as follows:

• check out the source code (debcheckout or apt-get source)
• if it’s in a repository, create a new branch with the patch I’m interested in
• if it’s not, apply the patch manually
• in both cases, increment the version with an appropriate changelog entry using dch -n (without committing it, to avoid merge issues)
• build the package and install it (in my case, via a local package repository)

When a new version of the package is released, I repeat the above; in the case of a source repository, I rebase the patch instead of starting from scratch.