Date: Mon, 4 Nov 2013 14:37:24 -0500 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Freddie Cash <fjwcash@gmail.com> Cc: Mike Jakubik <mike.jakubik@intertainservices.com>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: pkgng: how to upgrade a single port? Message-ID: <3884C60E-FFEC-413C-901E-631E2862984B@gromit.dlib.vt.edu> In-Reply-To: <CAOjFWZ4r-gWHd9k8F-T9sE1_5Qa0VVbqzxwYVZGazFf2b0k8VQ@mail.gmail.com> References: <527406D2.7010200@intertainservices.com> <1383336649.16326.41750369.298F8E9D@webmail.messagingengine.com> <1383337118.18823.41752849.2502EBFD@webmail.messagingengine.com> <CA%2BdUSyoUQB%2BgLM8g70y6mz7c%2BHSb3DJpVFvaENgm45VwcYVjQA@mail.gmail.com> <5277E53A.4090208@intertainservices.com> <CAOjFWZ4r-gWHd9k8F-T9sE1_5Qa0VVbqzxwYVZGazFf2b0k8VQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 4, 2013, at 1:56 PM, Freddie Cash <fjwcash@gmail.com> wrote:
> On Mon, Nov 4, 2013 at 10:19 AM, Mike Jakubik <
> mike.jakubik@intertainservices.com> wrote:
>=20
>> On 11/03/13 17:24, George Kontostanos wrote:
>>=20
>>> You can alway lock a package or the packages that you don't need to
>>> upgrade. See: "pkg help lock"
>>>=20
>>=20
>=20
>> 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.
>>=20
>=20
> It's not a limitation in the system; it's a disconnect between how =
things
> work and what you expect. :)
>=20
> 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.
>=20
> 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).
>=20
> 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.
>=20
> 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.
>=20
> 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3884C60E-FFEC-413C-901E-631E2862984B>