bcfg2 insists on updating held packages

[https://www.google.com/accounts/o8/id?id=AItOawkPb0RtPyicSdU7pLcv1UrX-yCh-YjkOwU]

Some packages are put on hold on my system, but when I run:

bcfg2 -q -v -n

it still shows message In dryrun mode: suppressing entry installation for:

[solj]

If you are using Packages, then this will be a problem with the client side. You can check by trying to aptitude dist-upgrade on the client which would also want to upgrade the packages in question.

If you are using Pkgmgr, you can specify explicitly the version you want.

[https://www.google.com/accounts/o8/id?id=AItOawkPb0RtPyicSdU7pLcv1UrX-yCh-YjkOwU]

I am using Packages. Why should I use aptitude dist-upgrade? I don't want to upgrade distribution - it not related IMO. aptitude upgrade doesn't propose to upgrade package in question, because it is put on hold explicitly.

[solj]

Replying to https://www.google.com/accounts/o8/id?id=AItOawkPb0RtPyicSdU7pLcv1UrX-yCh-YjkOwU:

I am using Packages. Why should I use aptitude dist-upgrade? I don't want to upgrade distribution - it not related IMO. aptitude upgrade doesn't propose to upgrade package in question, because it is put on hold explicitly.

I can't reproduce this. You'll need to provide more information. If you cache the client configuration bcfg2 -qnc cached.xml, you will see that Packages doesn't send any particular version to be installed. The client only sees version='auto'. Therefore, either the client wants to reinstall these packages for some other reason, or the client's apt is trying to do the upgrade.

[https://www.google.com/accounts/o8/id?id=AItOawkPb0RtPyicSdU7pLcv1UrX-yCh-YjkOwU]

I see. I am using aptitude and it's strange.

$ sudo aptitude upgrade   
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
                                         

However, apt-get proposes an update:

$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
   trac-bitten (0.6-1 => 0.6b2.dfsg-3)
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/88.8 kB of archives.
After this operation, 102 kB disk space will be freed.

Seems like apt-get and aptitude way of holding packages are incompatible or apt-get can't hold packages at all. Why not to use aptitude instead of apt-get? It ​look more appealing for automated configuration management. This stuff is an absolute must for any SCM tool IMO - mark packages as "automatically installed" or "manually installed" so that packages can be auto-removed when no longer required, and this feature is just nice-to-have - score-based and (usually) smarter dependency resolver than apt-get.

Sadly. there are a lot of related bugreports with no indication when they will be fixed. ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146207 =/

[solj]

Replying to https://www.google.com/accounts/o8/id?id=AItOawkPb0RtPyicSdU7pLcv1UrX-yCh-YjkOwU:

I see. I am using aptitude and it's strange.

$ sudo aptitude upgrade   
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
                                         

However, apt-get proposes an update:

$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
   trac-bitten (0.6-1 => 0.6b2.dfsg-3)
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/88.8 kB of archives.
After this operation, 102 kB disk space will be freed.

Seems like apt-get and aptitude way of holding packages are incompatible or apt-get can't hold packages at all. Why not to use aptitude instead of apt-get? It ​look more appealing for automated configuration management. This stuff is an absolute must for any SCM tool IMO - mark packages as "automatically installed" or "manually installed" so that packages can be auto-removed when no longer required, and this feature is just nice-to-have - score-based and (usually) smarter dependency resolver than apt-get.

Sadly. there are a lot of related bugreports with no indication when they will be fixed. ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146207 =/

Weird. I'll leave this ticket open for now so that we can contemplate switching over to aptitude. We debated it before and at that time we didn't see any benefit to switching, however, this seems like the sort of situation where we may want to make the switch. In the interim, you can use the instructions in section 3.10 at ​http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html to pin the packages for your current clients.