synaptic: ‘Lock Version’ is broken; use dpkg hold

Bug #42178 reported by towsonu2003
266
This bug affects 35 people
Affects Status Importance Assigned to Milestone
synaptic
Confirmed
Unknown
synaptic (Ubuntu)
Triaged
Low
Unassigned
Declined for Lucid by Julian Andres Klode

Bug Description

‘Lock Version’ in Synaptic uses apt_preferences(5) (“pinning”). This is never recognized by non-Apt tools, e.g. dpkg. Also, as these settings are stored in a file private to Synaptic, other Apt tools do not recognize them either.

This feature is to be removed. In its place implement support for dpkg holds which are handled properly by all Apt and Dpkg tools.

* Original Description

this is minor annoyance. but I figured, this might as well be a bug which might need to be fixed bf dapper comes out. I mean, I'm pretty sure I'll be pinning fx 1.5 in Dapper, when fx 2.0 comes out...

here is the problem:

I have fx 1.5.0.2 thus don't need the 1.0.8 update. I pinned it (and its friend, shown below) to 1.0.7 using synaptic's packages>lock version, but when I do apt-get upgrade, it still wants to upgrade firefox. synaptic is just fine, it doesn't prompt me to update fx. here is the output for your viewing pleasure:

Code:
:~$ sudo apt-get -s upgrade
Reading package lists...
Done Building dependency tree...
Done
The following packages will be upgraded:
firefox firefox-gnome-support
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst firefox-gnome-support [1.0.7-0ubuntu20] (1.0.8-0ubuntu5.10 Ubuntu:5.10/breezy-security) []
Inst firefox [1.0.7-0ubuntu20] (1.0.8-0ubuntu5.10 Ubuntu:5.10/breezy-security)
Conf firefox (1.0.8-0ubuntu5.10 Ubuntu:5.10/breezy-security)
Conf firefox-gnome-support (1.0.8-0ubuntu5.10 Ubuntu:5.10/breezy-security)

both of these were supposed to be pinned by synaptic...

Here is my cat /var/lib/synaptic/preferences
-------------
Package: firefox
Pin: version 1.0.7-0ubuntu20
Pin-Priority: 1001

Package: firefox-gnome-support
Pin: version 1.0.7-0ubuntu20
Pin-Priority: 1001
--------------

I don't have a /etc/apt/preferences which is ok

Thanks.

Revision history for this message
In , Michael Vogt (mvo) wrote : Re: Bug#276655: pinning/holding does not work

On Fri, Oct 15, 2004 at 03:00:11PM +0200, martin f krafft wrote:
> Package: synaptic
> Version: 0.53.4-5
> Severity: minor

Thanks for your bugreport.

> I assume the 'hold' you refer to in README.Debian is the 'locking'
> of a version in the interface's package menu. Well, I tried to lock
> APT to 0.5.26 for testing purposes, then installed a package and
> quit the programme. Subsequently, APT tried to update to APT 0.5.27
> from the command line.
>
> I noticed how you use ~/.synaptic/preference instead. I wonder why,
> but in any case... could you either
>
> - make synaptic use the global preferences file to incorporate it
> with the rest of the system, or
> - document that it uses pinning, but only internally. you might
> just leave that out since the it just does not matter and is of
> no interest.

I'll probably go with the second suggestion. Synaptic used to use the
global preferences file, but I removed this feature. The problem was,
that people got confused that locking inside synaptic broke there
apt-get upgrade/dist-upgrade. They filed bugs against apt about it.

thanks,
 Michael

> -- System Information:
> Debian Release: 3.1
> APT prefers testing
> APT policy: (600, 'testing'), (98, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
> Kernel: Linux 2.6.8-cirrus
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
>
> Versions of packages synaptic depends on:
> pn hermes1 Not found.
> pn libapt-pkg-libc6.2-3-2 Not found.
> ii libc6 2.3.2.ds1-17 GNU C Library: Shared libraries an
> ii libjpeg62 6b-9 The Independent JPEG Group's JPEG
> pn libpng2 Not found.
> ii libstdc++2.10-glibc2.2 1:2.95.4-11woody1 The GNU stdc++ library
> pn libtiff3g Not found.
> ii libungif4g 4.1.3-1 shared library for GIF images (run
> pn libwraster2 Not found.
> ii xlibs 4.3.0.dfsg.1-8 X Window System client libraries m
> ii zlib1g 1:1.2.2-1 compression library - runtime
>
> --
> Please do not CC me when replying to lists; I read them!
>
> .''`. martin f. krafft <email address hidden>
> : :' : proud Debian developer, admin, and user
> `. `'`
> `- Debian - when you have better things to do than fixing a system
>
> Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

--
The first rule of holes is: when you find yourself in one, stop digging. - PJ
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo

Revision history for this message
In , Filipus Klutiero (ido) wrote : Optional?

Hi, I'm not sure I understand Martin's suggestions, but if the situation
is that synaptic doesn't use /var/lib/dpkg/status to save the locked
packages because users were confused by apt-get being influenced by
synaptic so synaptic got its own file storing locked packages, please
consider this message as a wish to make optional using either the global
APT file or a synaptic-specific one.
I usually assume that a synaptic feature that has an effect equivalent
to an APT feature will be "compatible" with the APT feature, but the
current behavior of synaptic for locking breaks this expectation.

Revision history for this message
towsonu2003 (towsonu2003) wrote : apt-get doesn't listen to synaptic [breezy]

this is minor annoyance. but I figured, this might as well be a bug which might need to be fixed bf dapper comes out. I mean, I'm pretty sure I'll be pinning fx 1.5 in Dapper, when fx 2.0 comes out...

here is the problem:

I have fx 1.5.0.2 thus don't need the 1.0.8 update. I pinned it (and its friend, shown below) to 1.0.7 using synaptic's packages>lock version, but when I do apt-get upgrade, it still wants to upgrade firefox. synaptic is just fine, it doesn't prompt me to update fx. here is the output for your viewing pleasure:

Code:
:~$ sudo apt-get -s upgrade
Reading package lists...
Done Building dependency tree...
Done
The following packages will be upgraded:
firefox firefox-gnome-support
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst firefox-gnome-support [1.0.7-0ubuntu20] (1.0.8-0ubuntu5.10 Ubuntu:5.10/breezy-security) []
Inst firefox [1.0.7-0ubuntu20] (1.0.8-0ubuntu5.10 Ubuntu:5.10/breezy-security)
Conf firefox (1.0.8-0ubuntu5.10 Ubuntu:5.10/breezy-security)
Conf firefox-gnome-support (1.0.8-0ubuntu5.10 Ubuntu:5.10/breezy-security)

both of these were supposed to be pinned by synaptic...

Here is my cat /var/lib/synaptic/preferences
-------------
Package: firefox
Pin: version 1.0.7-0ubuntu20
Pin-Priority: 1001

Package: firefox-gnome-support
Pin: version 1.0.7-0ubuntu20
Pin-Priority: 1001
--------------

I don't have a /etc/apt/preferences which is ok

Thanks.

Revision history for this message
Sebastian Heinlein (glatzor) wrote :

Thanks for reporting. But solving this bug would require deeper code changes. Please be patient.

Changed in synaptic:
assignee: nobody → mvo
status: Unconfirmed → Confirmed
Revision history for this message
towsonu2003 (towsonu2003) wrote :

thanks. is there anything I can do to help? I'm no programmer, and I'm using dial up (read: don't make me download stuff :) ), but anything else?

Revision history for this message
Sebastian Heinlein (glatzor) wrote :

no sorry. i will nag michael vogt, the current lead developer of apt about this bug. it is around for years.

Revision history for this message
towsonu2003 (towsonu2003) wrote :

is there a workaround? I checked out the apt howto and a couple of other documents, but the pinning howtos do not mention package specific pinning...

any pointer would be extremely nice. I just don't wanna upgrade by mistake -thanks.

Revision history for this message
Michael Vogt (mvo) wrote :

The workaround would be to create a symlink from /var/lib/synaptic/preferences to /etc/apt/preferences.

I guess in the future I could add a option in synaptic preferences:
[ ] Apply pkg-hold systemwide

or something like this.

Cheers,
 Michael

Revision history for this message
towsonu2003 (towsonu2003) wrote : Re: apt-get doesn't use the same pinning as synaptic

I think this is solved to _some degree_ in Dapper (I don't have the workaround symlink). I have gaim (2beta) pinned via synaptic and apt doesn't suggest to upgrade them...

now the problem is, before I was posting this message, I unpinned the packages via synaptic, closed synaptic, issued apt-get update and:

~$ sudo apt-get -s upgrade
Reading package lists... Done
Building dependency tree... Done
The following packages have been kept back:
  gaim
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

now apt won't upgrade it :)

Changed in synaptic:
status: Unknown → Unconfirmed
Revision history for this message
rasz (citizenr) wrote :

still not working with the newest patched build of synaptics from : https://launchpad.net/bugs/67146

Michael Vogt (mvo)
Changed in synaptic:
importance: Unknown → Undecided
status: Unconfirmed → Confirmed
importance: Undecided → Medium
Changed in synaptic:
status: Confirmed → Unconfirmed
Christian Reis (kiko)
Changed in synaptic:
importance: Unknown → Undecided
Revision history for this message
Tormod Volden (tormodvolden) wrote :

Is this still a problem in 7.04 (and now that bug #67146 is fixed)?

Changed in synaptic:
status: Confirmed → Needs Info
Revision history for this message
Jean-Yves Lefort (jylefort) wrote :

Yes it is.

Changed in synaptic:
status: Needs Info → Confirmed
Revision history for this message
Old_Soldier (charles.davis) wrote :

still exists in 8.04

Changed in synaptic:
status: Confirmed → Triaged
Revision history for this message
Arnaud Soyez (weboide) wrote :

Bug confirmed and reproduceable in Hardy 8.04.1

Revision history for this message
Michael Ellerman (michael-ellerman) wrote :

Still broken in Intrepid 8.10 ..

Revision history for this message
Tiva (ugkbunb) wrote :

Still broken ni Jaunty. Easy to reproduce.

Revision history for this message
mtron (mtron) wrote :

still broken in kamic. Follow instructions above to reproduce

tags: added: pinning
Revision history for this message
Jonathon Fernyhough (jfernyhough) wrote :

Still broken in Lucid.

Workaround is only partial as it ignores /etc/apt/preferences.d/ in favour of the plain /etc/apt/preferences:
$ sudo rm /var/lib/synaptic/preferences
$ sudo ln -s /etc/apt/preferences /var/lib/synaptic/preferences

(might need to
$ sudo touch /etc/apt/preferences
if it doesn't already exist)

Revision history for this message
David Clayton (dcstar) wrote :

I have used aptitude to "pin" the packages I don't want changed whenever an "Upgrade" notice appears in the Update Manager - I hope that this stops my packages from being forcefully updated by this method.

Revision history for this message
emarkay (mrk) wrote :

Also (or related), "Recovery Console's", "Fix Broken Packages" also ignores any "Pinned" packages.

For example: I have Avidemux 2.4.4 Pinned in Synaptic to not upgrade, but this tool (in recovery menu) ignores that and automatically assigns the upgrade to Avidemux.

Since there are no options to select or deselect, this renders the entire tool unusable in this case.

Revision history for this message
Gabriel C. Stabel (gstabel) wrote :

Still broken in Ubuntu 10.10 (Maverick).

The partial Jonathon`s workaround (above) still working:
   $ sudo rm /var/lib/synaptic/preferences
   $ sudo ln -s /etc/apt/preferences /var/lib/synaptic/preferences

I got an unexpect server error this morning (openerp server freezes, and about ten people stop working) because my colegue administrator updates de server using apt-upgrade after I locked packages in Synaptic...
For me this is a bug, not a feature. "Everbody" treat Synaptic as GUI for apt.

Changed in synaptic (Ubuntu):
assignee: Michael Vogt (mvo) → nobody
importance: Medium → Low
Revision history for this message
steubens (steubens) wrote :

this recently made a bit of a mess on a new install (i add natty repos, pin at 50, then pull firefox from natty) where the file sharing dialogue and some other auto-foo installed natty packages, ignoring /etc/preferences.d/*, aptitude just got a patch to finally heed preferences.d in the natty cycle, it would be sweet to put this one to bed too

make synaptic read /etc/preferences.d/* and write its local changes to /etc/preferences.d/synaptic-pins or something

Revision history for this message
emarkay (mrk) wrote :

FWIW the last few posts confirm this could cause loss of work via unintended or unwanted action on a part of Ubuntu, yet it's been demoted in priority. This isn't a cosmetic or "fluff" issue, it relates to a fundamental concept that is flawed; intentionally protecting something by marking "pinned" it is ignored by the program in question.

Can this priority be elevated or at least reviewed?

Revision history for this message
hawran (hawran.diskuse) wrote :

I was about to report a new bug and found a couple of similar ones here:

As there's a plethora of Firefox's upgrades nowadays (and of Thunderbird's of course) I've locked a version within my Synaptic.
I expected the version being locked would not be upgraded without my explicit action.
However, I got my FF 8 upgraded to FF 9 when I run sudo apt-get upgrade/update.

What's wrong?
Does Synaptic lock packages on its own and the lower-level apps do not know about it?

PS
10.04 LTS - the Lucid Lynx
Linux ... 2.6.32-37-generic-pae #81-Ubuntu SMP Fri Dec 2 22:24:22 UTC 2011 i686 GNU/Linux
GNOME gnome-about 2.30.2

Revision history for this message
hawran (hawran.diskuse) wrote :
Revision history for this message
Benjamin Bach (benjaoming) wrote :

This is very confusing. It is not clearly mentioned that locking a package in Synaptic does not lock it in dpkg.

How to properly lock/freeze/hold a package:

    echo "package-name hold" | dpkg --set-selection

How to release a package for updates:

    echo "package-name install" | dpkg --set-selection

Why can synaptic not simply invoke the same interface? Is it because it locks the package database? And if so, then I think Synaptic should be liable to also lock packages properly.

Revision history for this message
Daniel Hartwig (wigs) wrote :

Aptitude also has private holds that apt is unaware of, and receives a lot of bugs about this issue. Based on the large number of reports over the years, has the time come to update aptitude and synaptic to use these global apt holds?

Michael, I am glad to take on this task in synaptic also, if you are open to it. Does synaptic use pinning for this feature because APT was unaware of /var/lib/dpkg/status holds at the time you implemented it?

Revision history for this message
B Bobo (yout-bobo123) wrote :

According to the first comment (bug #42178#bug-branches-container) I see synaptic was changed to use /var/lib/synaptic/preferences instead of the global preferences file /etc/apt/preferences to make it less confusing.

However, I think synaptic is actually much more confusing because of that change! It confsued me, and I wasted time trying to deal with it and filing bug #1166568. I agree with what Daniel Hartwig wrote in comment #27. I too would like to see the 2004 change reverted, so that synaptic uses the global preferences file in future. It seems better and more logical to do it that way.

Revision history for this message
Daniel Hartwig (wigs) wrote : Re: [Bug 42178] Re: apt-get doesn't use the same pinning as synaptic

On 31 May 2013 15:46, B Bobo <email address hidden> wrote:
> According to the first comment (bug #42178#bug-branches-container) I see
> synaptic was changed to use /var/lib/synaptic/preferences instead of the
> global preferences file /etc/apt/preferences to make it less confusing.
>
> However, I think synaptic is actually much more confusing because of
> that change! It confsued me, and I wasted time trying to deal with it
> and filing bug #1166568. I agree with what Daniel Hartwig wrote in
> comment #27. I too would like to see the 2004 change reverted, so that
> synaptic uses the global preferences file in future. It seems better and
> more logical to do it that way.
>

Actually this would not be reverting that change. Synaptic uses the
apt-preferences system, and the referenced change only concerns which
file stored those. Preferences is not ideal for holding packages, so
we will change synaptic to use the dpkg holds system which is
available to all dpkg and apt tools.

This would be an interesting task for someone who wants to learn
apt/synaptic development. Otherwise I will tackle it shortly as it is
important to have all these tools using the same system for holds.

Daniel Hartwig (wigs)
summary: - apt-get doesn't use the same pinning as synaptic
+ synaptic: ‘Lock Version’ is broken; use dpkg hold
description: updated
Changed in synaptic:
status: New → Confirmed
Norbert (nrbrtx)
tags: added: bionic trusty xenial
Revision history for this message
Norbert (nrbrtx) wrote :

It seems that bug is still actual for all LTS releases.

As I wrote on AskUbuntu question (https://askubuntu.com/q/1002703/66509) nowadays only Muon uses system-wide pinning in `/etc/apt/preferences.d/`.

Revision history for this message
Raimondo Giammanco (rai) wrote :

This bug is so old that its status should be changed in Won't Fix.

I don't see it, but it'll be a good reason if the developers do not want to implement the system-wide lock.

However, this behaviour should be clearly stated in the man synaptic(8) where it says instead:
> Synaptic is a frontend for the apt package managent system.
> It allows you to perform all actions of the command line tool apt-get in a graphical environemnt.
> This includes installing, upgrading, downgrading and removing of single packages
> or even upgrading your whole system.

And in the help menu of Synaptic, too. In the section "To Lock a Package to the Current Version (Debian only)" there is not enough emphasis on the fact that the actions aren't disabled system-wide

Revision history for this message
gf (gf-interlinks-deactivatedaccount) wrote :

Hello,

https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/1766161

has been marked a duplicate of this bug.
This issue may have been reported a long time ago, but it is still current problem.

A simple solution would be a pop-up window in synaptic when you lock an application, to warn the user that "...this loçk will only work in synaptic; if you use any other software to upgrade your computer, please engage the lock in that application as well..."

Would that work?
Thanks
G

Revision history for this message
EricDHH (ericdhh) wrote : Re: [Bug 42178] Re: synaptic: ‘Lock Version’ is broken; use dpkg hold

On my computers software update ignore locks in synaptic and dpkg too.
It would be better to fix software update or to remove the dysfunctional
function in both programs.
If a user set a lock for reason, the system should not override it.

Greetings
Eric

Revision history for this message
Carlos Sevcik (carlos-sevcik-s-gmail) wrote :

I am not sure its the same bug, but using Ubuntu 8.10 suddenly synaptic stopped working. If you click on the icon it requires sudoers password, and then nothing happens. If you try to run it from terminal it starts if you run it without administrative privileges. but sudo synaptic pails with this message:

sudo synaptic
[sudo] password for csevcik:
Invalid MIT-MAGIC-COOKIE-1 keyUnable to init server: Could not connect: Connection refused

(synaptic:4058): Gtk-WARNING **: 09:57:26.552: cannot open display: :0

Re installing synaptic does not help solving the problem.

Revision history for this message
Michael Lueck (mlueck) wrote :

I find it very odd to see the defect I just found moving from Xubuntu 16.04 to Xubuntu 20.04.2 and Synaptic not respecting locked package versions already reported as of 2006-04-29!

Synaptic, for us, had always respected when we would put a lock on a certain package. That is no longer respected in 20.04.2.

I inquired about the trouble here:
"20.04.2 system - Will not respect Synaptic package lock at a specific version"
https://ubuntuforums.org/showthread.php?t=2464498&p=14047839

The workaround I found is:

$ sudo apt-mark hold firefox-esr-mozilla-build
$ sudo apt-mark hold firefox-mozilla-build
$ apt-mark showhold
firefox-esr-mozilla-build
firefox-mozilla-build

When I started, apt-mark did not see the lock on the two packages the Synaptic UI still recognized.

Now Synaptic no longer tries to update the packages from the versions I want maintained.

So Synaptic appears not to leverage the same flag that apt-mark is using? That seems odd and incorrect if that is the case. I would think to be dpkg compatible, Synaptic should use the same flag as other dpkg / apt tools, no?

Anyway, for us this is a definite new break moving from 16.04 to 20.4.2 versions.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.