Date: Mon, 4 Nov 2013 16:11:45 -0500 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Adrian Chadd <adrian@freebsd.org> Cc: FreeBSD Stable <freebsd-stable@freebsd.org>, Mike Jakubik <mike.jakubik@intertainservices.com> Subject: Re: pkgng: how to upgrade a single port? Message-ID: <0AD00FF2-8F68-432D-BC7F-9672AD173163@gromit.dlib.vt.edu> In-Reply-To: <CAJ-Vmo=HE5%2BDHpHsEXTEK6Tnf4s7L-=XE_2xBcJ5%2B%2BnpwsZ-0g@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> <3884C60E-FFEC-413C-901E-631E2862984B@gromit.dlib.vt.edu> <CAJ-Vmo=HE5%2BDHpHsEXTEK6Tnf4s7L-=XE_2xBcJ5%2B%2BnpwsZ-0g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 4, 2013, at 3:19 PM, Adrian Chadd <adrian@freebsd.org> 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 <paul@gromit.dlib.vt.edu> wrote: >> On Nov 4, 2013, at 1:56 PM, Freddie Cash <fjwcash@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0AD00FF2-8F68-432D-BC7F-9672AD173163>