mpeg4ip requires IPv6?

Brandon D. Valentine brandon at
Thu Jan 6 13:57:25 PST 2005

On Thu, Jan 06, 2005 at 11:59:58AM -0800, Michael C. Shultz wrote:
> On Thursday 06 January 2005 10:38 am, Scott I. Remick wrote:
> > On Thu, 6 Jan 2005 08:51:49 -0800, Michael C. Shultz wrote:
> > > It will update the out of date dependencies but if you
> > > have been running pkgdb -F from portupgrade then portmanager may
> > > miss a few because pkgdb screws up the ports registration data
> > > base.
> > I have. :( Do the outputs above suggest that using portmanager isn't
> > going to do much for me?
> It won't get your system perfect at first because it isn't picking up 
> many of the lower dependencies, likely because pkgdb made too many 
> changes to the registry,  I say you should run portmanager anyways 
> because it will start getting things right over time and never ever run 
> pkgdb again.  As the lower dependencies (like gettext, glib, gtk etc) 
> are updated in CVS and you get them with cvsup, then running 
> portmanager will get everthing built correctly that use those updated 
> dependencies, so in the long run things will improve for you.


I've been looking at portmanager pretty seriously for a few days now,
trying to determine whether it would solve my complaints about
portupgrade -- primarily the pkgdb mangling you talk about which has
caused me headaches in the past.  I very much like the fact that it
seems to always DTRT by rebuilding or upgrading a package when one of
its dependencies is upgraded.

You mention above the fact that after switching to portmanager, a
package whose dependency list was mangled via pkgdb -F will not be
rebuilt until that package or a dependency of that package is updated in
CVS and portmanager schedules it for a rebuild.  In contemplating my own
switch to portmanager, I came to the conclusion that prior to switching
it would be worthwhile to do something akin to portupgrade -af that
would rebuild _ALL_ installed ports, hopefully restoring the ports
system and pkg database to a consistent state.  Scott might want to
consider this as a way to clean up his dependency mess.  This mostly
works though it has been my experience with portupgrade that when
tackling that many ports, something will surely break and require
attention along the way.  If you stick with it though you'll eventually
get a portupgrade -af to run from start to finish and your system will
be in a consistent state.

There are a few things that portmanager does not currently do that would
make it more valuable as a portupgrade replacement.  

Any plans to add the ability to do 'portmanager -u category/port' or
some similar syntax that would upgrade a specific port and all of its
dependencies and dependent packages as well?

Have you thought about the utility of a -f flag to portmanager to say,
even if something isn't out of date, force an upgrade anyway?  I can see
this being a better replacement for the portupgrade -af that I mentioned

Have you considered adding the ability to exclude or hold specific
packages from being upgraded?  This would need to recursively hold any
related packages to be possible, but it should be made possible in order
to allow large suites of software like KDE, Gnome, OpenOffice, the JDK,
mozilla, etc to escape a mandatory upgrade.

It looks like a potentially nice tool.


Pseudo-Random Googlism:  snow is cold work

More information about the freebsd-ports mailing list