Date: Fri, 9 Feb 2007 00:27:00 +0100 From: Joan Picanyol i Puig <lists-freebsd@biaix.org> To: freebsd-ports@freebsd.org Subject: Re: pkg_upgrade (was Re: pkg_add does not backtrack, does it?) Message-ID: <20070208232700.GB90289@grummit.biaix.org> In-Reply-To: <17865.28442.623829.375834@bhuda.mired.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>
next in thread | previous in thread | raw e-mail | index | archive | help
[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. qvb -- pica
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070208232700.GB90289>