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.