From owner-freebsd-stable@FreeBSD.ORG Mon Nov 4 21:12:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 02E3E30C; Mon, 4 Nov 2013 21:12:18 +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 AC67D2354; Mon, 4 Nov 2013 21:12:17 +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 rA4LBkbW029557; Mon, 4 Nov 2013 16:11:46 -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 rA4LBjKK020164; Mon, 4 Nov 2013 16:11:45 -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 rA4LBjSN010162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Nov 2013 16:11:45 -0500 Content-Type: text/plain; charset=iso-8859-1 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 16:11:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0AD00FF2-8F68-432D-BC7F-9672AD173163@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> <3884C60E-FFEC-413C-901E-631E2862984B@gromit.dlib.vt.edu> To: Adrian Chadd X-Mailer: Apple Mail (2.1816) X-Spam-Status: No, score=0.5 required=5.0 tests=FUZZY_VPILL,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: FreeBSD Stable , Mike Jakubik 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 21:12:18 -0000 On Nov 4, 2013, at 3:19 PM, Adrian Chadd wrote: > Hi, >=20 > Just please keep in mind that when it claims the same version package > needs to be reinstalled, it seems to be for a good reason. Eg, the > base system library dependencies have changed. >=20 > Since there's no "stable" package snapshot, various package versions > get upgraded all the time. A package update to fix a security > vulnerability may have occured whilst its dependencies got updated, so > you have to upgrade the dependencies. And their dependencies. etc, > etc. I appreciate that, and that is why package managers have dependency = solvers that can work out which packages must be updated. But, as I = pointed out below, there are also cases where not all packages need to = be upgraded at once yet, ostensibly, "pkg upgrade" only supports this = method of upgrading (everything en masse). I have stumbled across this = use case myself. For example, one time there was a critical Java = security update to openjdk7 but also apache-solr had updated from = version 4.1 to 4.4 in our poudriere repo. I wanted to upgrade openjdk7 = but not apache-solr at that time, because I wanted to check that the = software we were developing that used Solr was compatible with 4.4. = Being able just to do "pkg upgrade openjdk7" would have been the = intuitive path there. (I wasn't at that time aware of "pkg install = openjdk7" to achieve the same end, so I ended up "pkg lock apache-solr" = followed by "pkg upgrade" instead, which ended up not quite working 100% = due to implementation bugs in pkg lock.) Maybe the original poster is familiar with "yum" which allows you to = update individual packages or update all packages. Looking at pkgng, it = appears it is modelled after Debian's apt-get in that it, too, uses = "install foo" to update package "foo" if it is already installed. = (Apt-get also has the "--only-upgrade" option.) I guess once you realise pkg is close in syntax and semantics to apt-get = then things make more sense. Otherwise, it seems counterintuitive that = "pkg upgrade" doesn't work for individual packages given that many = package managers allow this. It would also be more helpful if the man page for "pkg install" made it = more explicit that it will also upgrade a package that is already = installed. E.g., under "NAME" have instead "pkg install -- installs or = upgrades packages from remote package repositories". The first = paragraph under "DESCRIPTION" should also mention this use case. Of = course, having "pkg upgrade foo" behave like "pkg install foo" when = "foo" is already installed would be a bonus, too. That would make it = diverge from the apt-get syntax, though. Cheers, Paul. >=20 >=20 >=20 > -adrian >=20 >=20 > On 4 November 2013 11:37, Paul Mather wrote: >> On Nov 4, 2013, at 1:56 PM, Freddie Cash wrote: >>=20 >>> 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. >>=20 >>=20 >> 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. >>=20 >> 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"): >>=20 >> 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. >>=20 >>=20 >> 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.) >>=20 >> Cheers, >>=20 >> Paul. >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >=20