Is pkgng supposed to upgrade a dependency of a locked package?

Matthew Seaman matthew at
Thu Jul 18 12:56:31 UTC 2013

On 18/07/2013 13:42, Paul Mather wrote:
> I am using pkgng 1.1.4_1 on RELENG_9 (r252725), operating on a local repo I maintain using poudriere 3.0.4.
> Recently, I wanted to upgrade all packages on a client except two whose update I want to defer for now as they potentially impact locally-developed applications.  I figured I would use the pkgng "lock" functionality on those two packages (apache-solr and py27-Jinja2) to prevent them from being updated.  I ran "pkg upgrade" on the client and, as expected, the locked packages weren't upgraded.  However, I was surprised to see that packages upon which the locked packages depended were upgraded.  Unless I'm misunderstanding something, the man page for pkg-lock states this should not happen:
> =====
>      The impact of locking a package is wider than simply preventing modifica-
>      tions to the package itself.  Any operation implying modification of the
>      locked package will be blocked.  This includes:
> [[...]]
>      o   Deletion, up- or downgrade of any package the locked package depends
>          upon, either directly or as a consequence of installing or upgrading
>          some third package.
> =====
> In my case, the following dependencies of apache-solr were updated, even though apache-solr is locked: java-zoneinfo: 2013.c -> 2013.d; libXi: 1.7.1_1,1 -> 1.7.2,1; libXrender: 0.9.7_1 -> 0.9.8; and openjdk: 7.21.11 -> 7.25.15.  In the case of the locked py27-Jinja2, these dependencies were updated: gettext: -> 0.18.3; and py27-MarkupSafe: 0.15 -> 0.18.  Dependency information in the two locked packages was updated to reflect these new, upgraded dependencies.
> Is this a bug, or am I misreading the man page?

That's a bug, definitely.  The way the man page describes the effect of
locking is what should happen -- nothing a locked package depends on
should be modified by pkg without some extra input from the
administrator to allow the change to happen.



More information about the freebsd-questions mailing list