Date: Fri, 9 Feb 2007 13:40:52 +0100 From: Kirill Ponomarew <krion@voodoo.bawue.com> To: Joan Picanyol i Puig <lists-freebsd@biaix.org> Cc: freebsd-ports@freebsd.org Subject: Re: pkg_upgrade (was Re: pkg_add does not backtrack, does it?) Message-ID: <20070209124052.GE9650@voodoo.bawue.com> In-Reply-To: <20070208232700.GB90289@grummit.biaix.org> References: <8b4c81f0702061514r5a753e48yea0ce9b937236fc3@mail.gmail.com> <17865.6041.605201.772296@bhuda.mired.org> <20070207020205.GC62321@grummit.biaix.org> <17865.28442.623829.375834@bhuda.mired.org> <20070208232700.GB90289@grummit.biaix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 09, 2007 at 12:27:00AM +0100, Joan Picanyol i Puig wrote: > [moved to ports@ with notice in hackers@] > > * Mike Meyer <mwm@mired.org> [20070207 07:17]: > > In <20070207020205.GC62321@grummit.biaix.org>, Joan Picanyol i Puig <lists-freebsd-hackers@biaix.org> typed: > > > I know what I'd like: a utility in the base system for binary upgrading > > > of packages. More flexible logic in how the '-r' option is handled would > > > be nice (being able to fetch all packages from All/ even if you are > > > on RELENG). Doesn't > > > > > > freebsd-update fetch install && pkg_upgrade -a > > > > > > look nice for keeping up to date? > > > > Not particularly, but why does it have to be in the base system? > > freebsd-update isn't. > > It is, but my point is that I take "base system" as better integration. > > > > The obvious hairy details must be harder than it seems, I'm sure > > > others have considered it (and would have done it) before. > > > > The thing is, chances are pretty good that at some point or another, > > you're *not* going to want to just update all the installed > > packages. Some package may require external work, or you may want to > > follow a different branch than the main port, or an update may include > > a new bug that you can't live with, > > I'm aware of the limitations of going with a "third-party" provided > binaries approach to package management. However, I expect to be trading > off flexibility for convinience but the convinience is nowhere to be > found. > > > or you may have something installed that's not in the ports tree that > > breaks if you update a port, etc. > > > > And of course, this doesn't work well if you've managed to corrupt the > > ports database, which is all to easy to do. Or at least I've found > > that to be the case. Maybe if I could only convince myself to *always* > > use portinstall, and not just do a "make install" after I've read > > through the package description, things wouldn't be so bad, but they > > are. > > I don't expect any binary package management system to cope with > anything different than itself. The fact that you (and me) are able to > "corrupt the ports database", which portupgrade can do even without > mixing binary and source packages tells me that it can't be depended on. > > > People have tried this. portupgrade is the most complete solution I > > know of, though there are others in the ports tree. It can do > > binary-only upgrades, or can be set to try the binaries first, and > > only build if the binaries aren't available. It also has flags to save > > the old install, and a config file that lets you hold packages, or set > > build options if you build. > > Been there, done that, cried. I've also tried portmanager and portmaster > (which I'm using now with portsconf for source-based systems). My wish > is pkg_update, which can be used to upgrade pkg_add'ed packages. You can use portupgrade -PP -Kirill
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070209124052.GE9650>