pkg lock doesn't work if a dependency wants an upgrade
Adam McDougall
mcdouga9 at egr.msu.edu
Sun Mar 6 03:03:44 UTC 2016
What can I do to help diagnose this? I have setup an isolated test
system where I can easily return it to a pre-upgraded state. I don't
remember pkg printing a list of locked packages in the past so my faith
in proper operation was increased but I was tricked. It looks like pkg
upgraded postfix anyway because mailman depends on postfix. If I lock
both postfix and mailman, pkg leaves postfix alone. Why can't the
action of upgrading a package make a last minute check to make sure a
package is not locked? Additionally why would upgrading a package cause
it to become unlocked? Thanks.
Note: I am not interested in formally modifying things so they avoid
upgrading to postfix 3. I plan to upgrade soon but not tonight.
# pkg lock postfix
postfix-2.11.7_1,1: lock this package? [y/N]: y
Locking postfix-2.11.7_1,1
# pkg lock -l
Currently locked packages:
postfix-2.11.7_1,1
# pkg query %ro postfix
mail/mailman
# pkg upgrade
Updating pkg-2015 repository catalogue...
pkg-2015 repository is up-to-date.
All repositories are up-to-date.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):
Installed packages to be UPGRADED:
pkg: 1.6.4 -> 1.6.4_1
The operation will free 64 B.
2 MiB to be downloaded.
Proceed with this action? [y/N]: y
Fetching pkg-1.6.4_1.txz: 100% 2 MiB 2.5MB/s 00:01
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.6.4 to 1.6.4_1...
[1/1] Extracting pkg-1.6.4_1: 100%
Updating pkg-2015 repository catalogue...
pkg-2015 repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (6 candidates): 100%
Processing candidates (6 candidates): 16%
postfix-2.11.7_1,1 is locked and may not be modified
Processing candidates (6 candidates): 100%
The following 8 package(s) will be affected (of 0 checked):
Installed packages LOCKED:
Package postfix-2.11.7_1,1 is locked and may not be upgraded to
version 3.1.0,1
New packages to be INSTALLED: (don't worry about this part, it is from a
package I left off)
icu: 55.1
python: 2.7_2,2
Installed packages to be UPGRADED:
openssh-portable: 7.1.p2,1 -> 7.2.p1,1
mailman: 2.1.20_2 -> 2.1.21_3
krb5: 1.14 -> 1.14.1
ca_root_nss: 3.22 -> 3.22.2
The process will require 68 MiB more space.
20 MiB to be downloaded.
Proceed with this action? [y/N]: y
Fetching openssh-portable-7.2.p1,1.txz: 100% 699 KiB 715.6kB/s 00:01
Fetching mailman-2.1.21_3.txz: 100% 3 MiB 3.6MB/s 00:01
Fetching krb5-1.14.1.txz: 100% 1 MiB 1.1MB/s 00:01
Fetching ca_root_nss-3.22.2.txz: 100% 322 KiB 330.2kB/s 00:01
Fetching postfix-3.1.0,1.txz: 100% 1 MiB 1.6MB/s 00:01
Fetching icu-55.1.txz: 100% 14 MiB 15.1MB/s 00:01
Fetching python-2.7_2,2.txz: 100% 996 B 1.0kB/s 00:01
Checking integrity... done (0 conflicting)
[1/8] Upgrading krb5 from 1.14 to 1.14.1...
[1/8] Extracting krb5-1.14.1: 100%
[2/8] Installing icu-55.1...
[2/8] Extracting icu-55.1: 100%
[3/8] Upgrading ca_root_nss from 3.22 to 3.22.2...
[3/8] Extracting ca_root_nss-3.22.2: 100%
[4/8] Upgrading postfix from 2.11.7_1,1 to 3.1.0,1...
You may need to manually remove /usr/local/etc/postfix/main.cf if it is
no longer needed.
==> You should manually remove the "postfix" user.
===> Creating users and/or groups.
Using existing group 'mail'.
Using existing group 'maildrop'.
Using existing group 'postfix'.
Using existing user 'postfix'.
[4/8] Extracting postfix-3.1.0,1: 100%
===============================================================
Postfix already activated in /etc/mail/mailer.conf
===============================================================
postfix: Postfix is running with backwards-compatible default settings
postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details
postfix: To disable backwards compatibility use "postconf
compatibility_level=2" and "postfix reload"
postfix/postfix-script: refreshing the Postfix mail system
<...>
# pkg lock -l
Currently locked packages:
#
More information about the freebsd-ports
mailing list