pkg_upgrade (was Re: pkg_add does not backtrack, does it?)

[Kirill Ponomarew]

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 at mired.org> [20070207 07:17]:
> > In <20070207020205.GC62321 at grummit.biaix.org>, Joan Picanyol i Puig <lists-freebsd-hackers at 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