From owner-freebsd-stable@FreeBSD.ORG Mon Nov 4 19:38:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A33CD506 for ; Mon, 4 Nov 2013 19:38:02 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B1F72D47 for ; Mon, 4 Nov 2013 19:38:01 +0000 (UTC) Received: from mr3.cc.vt.edu (mr3.cc.vt.edu [198.82.141.68]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id rA4JbPFR021895; Mon, 4 Nov 2013 14:37:25 -0500 Received: from auth1.smtp.vt.edu (auth1.smtp.vt.edu [198.82.161.152]) by mr3.cc.vt.edu (8.14.4/8.14.4) with ESMTP id rA4JbPDR016002; Mon, 4 Nov 2013 14:37:25 -0500 Received: from [IPv6:2001:468:c80:c111:6951:4de:8061:c4b6] ([IPv6:2001:468:c80:c111:6951:4de:8061:c4b6]) (authenticated bits=0) by auth1.smtp.vt.edu (8.14.4/8.14.4) with ESMTP id rA4JbOj0004904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Nov 2013 14:37:24 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Subject: Re: pkgng: how to upgrade a single port? From: Paul Mather In-Reply-To: Date: Mon, 4 Nov 2013 14:37:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3884C60E-FFEC-413C-901E-631E2862984B@gromit.dlib.vt.edu> References: <527406D2.7010200@intertainservices.com> <1383336649.16326.41750369.298F8E9D@webmail.messagingengine.com> <1383337118.18823.41752849.2502EBFD@webmail.messagingengine.com> <5277E53A.4090208@intertainservices.com> To: Freddie Cash X-Mailer: Apple Mail (2.1816) X-Spam-Status: No, score=-0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mr3.cc.vt.edu Cc: Mike Jakubik , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:38:02 -0000 On Nov 4, 2013, at 1:56 PM, Freddie Cash 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.=