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

[Joan Picanyol i Puig]

[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.

qvb
-- 
pica