Control: tags 276655 + patch
Attached is a patch that makes "Lock Version" also set a real dpkg
hold, rather than only recording the pin in synaptic's own private
preferences file (RStateDir()/preferences), which apt-get/apt on the
command line never read -- reproducing exactly the symptom in the
original report.
This doesn't replace the existing internal pin-file mechanism (which
synaptic's own UI/status logic still relies on), it adds a real,
system-wide dpkg hold alongside it, using the same popen() pattern
already used elsewhere in this codebase (see gtk/rgdebinstallprogress.cc
for the existing system()/popen() convention for invoking dpkg).
I know there's a 2014 branch (lp:~mvo/synaptic/use-dpkg-hold) that
looks like it was meant to be a more complete replacement of the
private-pin approach -- I didn't have practical access to fetch an old
Launchpad bzr branch, so this is a smaller, independent, from-scratch
fix targeting the exact reported symptom rather than an attempt to
finish that branch's likely broader scope. Happy to adjust if that
branch's approach is still preferred.
Verified:
- Full dpkg-buildpackage build succeeds against the current 0.91.7
source with this patch applied, producing a real synaptic .deb
- The new setDpkgHold() function and its call site produce zero
compiler warnings under -Wall -Wextra (the only warnings in this
translation unit are pre-existing and unrelated, in the same
function, predating this patch)
- Patch applies cleanly against a fresh pristine 0.91.7 source tree
synaptic already runs its whole GUI session as root via the
synaptic-pkexec launcher (checked debian/synaptic.desktop.in), so
calling dpkg --set-selections directly from the UI action has the
privileges it needs without further plumbing.
Changes:
- common/rpackage.cc (new static helper + one call site)
- debian/changelog
--- a/common/rpackage.cc 2025-04-06 22:12:43.000000000 +0300
+++ b/common/rpackage.cc 2026-10-07 10:44:29.625054593 +0300
@@ -1047,6 +1047,19 @@
}
+// "Lock Version" only recorded the pin in synaptic's own private
+// preferences file (RStateDir()/preferences), which apt-get/apt on the
+// command line never reads. Also set a real dpkg hold so the lock is
+// honoured outside synaptic too (Debian #276655).
+static void setDpkgHold(const string &pkgname, bool flag)
+{
+ FILE *dpkg = popen("dpkg --set-selections", "w");
+ if (dpkg == NULL)
+ return;
+ fprintf(dpkg, "%s %s\n", pkgname.c_str(), flag ? "hold" : "install");
+ pclose(dpkg);
+}
+
void RPackage::setPinned(bool flag)
{
FILE *out;
@@ -1056,6 +1069,8 @@
_boolFlags = flag ? (_boolFlags | FPinned) : (_boolFlags & FPinned);
+ setDpkgHold(name(), flag);
+
if (flag) {
// pkg already in pin-file
if (_roptions->getPackageLock(name()))
--- a/debian/changelog 2025-04-06 22:12:43.000000000 +0300
+++ b/debian/changelog 2026-10-07 10:49:04.800088386 +0300
@@ -1,3 +1,14 @@
+synaptic (0.91.7+patch1) UNRELEASED; urgency=medium
+
+ * Also set a real dpkg hold when "Lock Version" is used, not just
+ synaptic's own private apt-preferences pin file (Closes: #276655).
+ Previously, locking a package's version in Synaptic had no effect
+ on apt-get/apt run from the command line, since they never read
+ RStateDir()/preferences. Verified with a full dpkg-buildpackage
+ build; the new code path produces no compiler warnings beyond
+ pre-existing unrelated ones in the same function.
+
+ -- Stefan Andrei Ionut <[email protected]> Wed, 7 Oct 2026 10:48:42 +0300
synaptic (0.91.7) unstable; urgency=medium
* common: use `_system->{,Un}LockInner()`
