Date: Mon, 4 Nov 2013 14:15:18 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Paul Mather <paul@gromit.dlib.vt.edu> Cc: FreeBSD Stable <freebsd-stable@freebsd.org>, Mike Jakubik <mike.jakubik@intertainservices.com> Subject: Re: pkgng: how to upgrade a single port? Message-ID: <CAJ-VmonsNRh%2B7isVEqrqks=O4wE31qWx%2BuqMeFgDPzsMkacfdw@mail.gmail.com> In-Reply-To: <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> <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> <0AD00FF2-8F68-432D-BC7F-9672AD173163@gromit.dlib.vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Yes, all the things you've said are correct. But once that's all said and done, you're still going to end up occasionally (or not so occasionally) hitting issues where upgrading a package without upgrading the dependencies ends up _breaking_ things. A lot of what makes yum/apt/etc work is because they have a stable package set and this hides all of the crap surrounding dependency changing hell. Things are much more exciting if you run debian-testing though (ie, you get exactly what you described with openjdk / apache-solr.) -adrian On 4 November 2013 13:11, Paul Mather <paul@gromit.dlib.vt.edu> wrote: > > On Nov 4, 2013, at 3:19 PM, Adrian Chadd <adrian@freebsd.org> wrote: > >> Hi, >> >> 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. >> >> 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 solve= rs 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 e= xample, 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 com= patible 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 instal= l openjdk7" to achieve the same end, so I ended up "pkg lock apache-solr" f= ollowed 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 upda= te individual packages or update all packages. Looking at pkgng, it appear= s 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 mana= gers allow this. > > It would also be more helpful if the man page for "pkg install" made it m= ore explicit that it will also upgrade a package that is already installed.= E.g., under "NAME" have instead "pkg install -- installs or upgrades pack= ages from remote package repositories". The first paragraph under "DESCRIP= TION" should also mention this use case. Of course, having "pkg upgrade fo= o" 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. > >> >> >> >> -adrian >> >> >> 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: >>> >>>> On Mon, Nov 4, 2013 at 10:19 AM, Mike Jakubik < >>>> mike.jakubik@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 depend= ency >>>>> 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 thi= ngs >>>> work and what you expect. :) >>>> >>>> The official packages are built using the default options for each por= t, >>>> and they are created in a single batch. They are designed to be upgra= ded >>>> 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 f= ile >>>> (ie, never run "pkg update" and add -U to all commands) so that everyt= hing >>>> 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; al= ways >>>> 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 howeve= r you >>>> want; ability to upgrade indibidual ports; not have to compile everyth= ing >>>> 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 upg= raded >>>> 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 package= s. (Sort of "yum update foo" rather than just "yum update".) The main sce= nario is that a package gets a security vulnerability (and so has high prio= rity for me to update) and I want to be able to update that package on a ma= chine (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 pack= ages I don't want updated, but locking the majority of packages I don't wan= t to update rather than just updating the minority of packages I want to se= ems inconvenient to me. >>> >>> However, it seems like "pkg install foo" will behave like "yum update f= oo" 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 th= e work >>> list as upgrade jobs. The work list is sorted into dependency orde= r and >>> pkg install will present it to the user for approval before proceed= ing, >>> 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 wo= uld be nice if "pkg upgrade foo" was a synonym for "pkg install foo" where = "foo" is already installed.) >>> >>> Cheers, >>> >>> 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.or= g" >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonsNRh%2B7isVEqrqks=O4wE31qWx%2BuqMeFgDPzsMkacfdw>