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

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.

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

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?

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

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.

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

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 :)

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

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

Yes it is.

still exists in 8.04

Bug confirmed and reproduceable in Hardy 8.04.1

Still broken in Intrepid 8.10 ..

Still broken ni Jaunty. Easy to reproduce.

still broken in kamic. Follow instructions above to reproduce

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)

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.

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.

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.

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

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?

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

Not to mention this:
https://help.ubuntu.com/community/PinningHowto#Synaptic

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.

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?

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.

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.

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/`.

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

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

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

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.

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.