portupgrade -- is there a way to only build and update ports that actually NEED it?

Daniel Staal DStaal at usa.net
Mon Jun 25 16:48:31 UTC 2012

On 2012-06-25 11:47, John Levine wrote:
>>You would think there's an option to portupgrade that says "don't 
>> upgrade
>>every single package I've got, but if somewhere in the dependency 
>> chain I
>>need a newer version of a thing, then do it."
> The problem is that the versioning in the ports system doesn't
> distinguish between upgrades that present interface changes and
> upgrades that are just nits, new features, or minor bug fixes.
> Port makefiles can contain version dependency info, e.g., this
> port needs at least version N.M of package X, but few of them do.
> This has bitten me in the past with PHP and pcre.  In fact, PHP5
> won't work with old versions of pcre, but the PHP port maintainer
> refuses to put in version dependency info, because he thinks that
> every port should be up to date all the time.

There's also the issue of things like Perl modules - most of them will 
just work, even with a newer version of perl, but a few have sections 
that need to be compiled against perl itself.  So if you update the Perl 
port, you need to at least recompile those.  (I'm simplifying a bit.)  
But there is no good way to mark in general which ports will 'just work' 
with an updated dependency, and which care what version of the 
dependency was installed when they were compiled.  This is separate from 
versioned dependencies: Again to use Perl modules as an example, DBI for 
instance is will work with any version of perl since 5.8 or so - but if 
you change which version of perl you are using you'll need to recompile 
and reinstall.

Rebuilding everything is a bit overkill, but it beats missing one that 
needed to be rebuilt.

Daniel T. Staal

This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.

More information about the freebsd-questions mailing list