pkgng: how to upgrade a single port?

Paul Mather paul at gromit.dlib.vt.edu
Mon Nov 4 19:38:02 UTC 2013


On Nov 4, 2013, at 1:56 PM, Freddie Cash <fjwcash at gmail.com> wrote:

> On Mon, Nov 4, 2013 at 10:19 AM, Mike Jakubik <
> mike.jakubik at intertainservices.com> wrote:
> 
>> On 11/03/13 17:24, George Kontostanos wrote:
>> 
>>> You can alway lock a package or the packages that you don't need to
>>> upgrade. See: "pkg help lock"
>>> 
>> 
> 
>> Thanks for the info but that would be very tedious to do. Is it just me or
>> is this a gross oversight of this new pkg system? Also the fact that with a
>> pkg you can not choose any options for the port, you have to install with
>> options that the port maintainer chose. As it stands now if i do pkg
>> upgrade it wants to pull in a bunch of stuff that i do not want, also it
>> wants to re-install just about everything because of a "direct dependency
>> changed", im not sure this is correct as it wanted to re-install pkg itself
>> just after I freshly installed it from ports.
>> 
> 
> It's not a limitation in the system; it's a disconnect between how things
> work and what you expect.  :)
> 
> The official packages are built using the default options for each port,
> and they are created in a single batch.  They are designed to be upgraded
> all at once so that everything is from the same compilation run, using the
> same builds of dependencies, etc.
> 
> It's expected that you will either never update the local repository file
> (ie, never run "pkg update" and add -U to all commands) so that everything
> is installed from the same repo version; or that you will specify a
> specific date in the repo path; or that you will upgrade everything in
> lock-step with the repo (always run "pkg update" before an install; always
> run a "pkg upgrade" after an update).
> 
> If you want the most flexibility in how ports are configured, ability to
> install a single port, upgrade a single port, etc, then it's expected that
> you would use the ports tree directly, and compile everything yourself.
> 
> If you want the best of both worlds (ability to configure ports however you
> want; ability to upgrade indibidual ports; not have to compile everything
> for every little change; etc) then you want to look into
> ports-mgmt/poudriere.  That allows you to create local pkg repos of
> packages built however you like.  And you control when a port gets upgraded
> in the pkg repo, and which dependencies get upgraded in the local pkg repo,
> etc.
> 
> It sounds like poudriere is what you want, not the official pkg repo.


I use poudriere but I also want to be able to update individual packages.  (Sort of "yum update foo" rather than just "yum update".)  The main scenario is that a package gets a security vulnerability (and so has high priority for me to update) and I want to be able to update that package on a machine (and packages that depend on it) but not others that are also updated in the repo (which might need more local testing and changes before I want to install the updated version).  I could achieve this by locking the packages I don't want updated, but locking the majority of packages I don't want to update rather than just updating the minority of packages I want to seems inconvenient to me.

However, it seems like "pkg install foo" will behave like "yum update foo" for installed package "foo" (this is from the man page for "pkg install"):

     Any already installed but out of date packages, either named on the com-
     mand line or from the sum of all their dependencies are added to the work
     list as upgrade jobs.  The work list is sorted into dependency order and
     pkg install will present it to the user for approval before proceeding,
     unless overridden by the -y option or the ASSUME_ALWAYS_YES setting in
     pkg.conf.


So, you can apparently update individual packages, even though you use the somewhat confusingly named mechanism of "pkg install" to do so.  (It would be nice if "pkg upgrade foo" was a synonym for "pkg install foo" where "foo" is already installed.)

Cheers,

Paul.


More information about the freebsd-stable mailing list