portupgrade -ar (why?)

Petersen petersen at petersen.plus.com
Sat Oct 15 13:52:46 PDT 2005


owner-freebsd-questions at freebsd.org <> wrote:
> --- Jan Grant <Jan.Grant at bristol.ac.uk> wrote:
> 
>> On Sat, 15 Oct 2005, Peter Matulis wrote:
>> 
>>> What is the use of specifying the 'r' switch when using the 'a'
>>> switch? 
>>> 
>>> # portupgrade -ar
>>> 
>>> This says to upgrade all ports plus the ones that depend on all
>>> those ports.  Am I missing something?  Wouldn't "the ones that
>>> depend" be upgraded anyway?
>> 
>> Not necessarily. For instance: package P might use library L. A
>> change in L might alter the size and layout of structures exposed to
>> P. The source-level API of L is unchanged; the binary-level ABI is
>> altered. So whilst the source code of P might not have changed, it
>> might (for instance) be using a macro defined by a header in L that
>> will look at the wrong offset in the new structure. These kinds of
>> ABI compatibility problems can be fixed by recompilihng P.
> 
> But still, a port requires upgrading or it does not.  Using 'r',
> portupgrade ultimately checks whether some port should be upgraded.
> Are you saying that the 'r' switch involves a different decision
> making process than 'a'? 
> 
> 

The -a switch will upgrade a port only if its version number has
increased (as you know).

The -r switch will upgrade a port if one of its dependancies has been
upgraded, regardless of whether its version number has changed or not.

e.g.

Appbar-1.0 depends on libfoo-1.0. Libfoo gets a portbump to 1.1.
portupgrade -r libfoo will install libfoo-1.1, plus also force a
recompile and reinstallation of appbar-1.0, irrespective of the fact
that appbar's version remains the same. Thus, any ABI changes that
happened in libfoo that could potentially break appbar that was
compiled/linked against the previous version are limited.

In an ideal world, this wouldn't be a problem. ABIs and APIs should
remain constant, until a library revision bump (i.e., if libfoo.1's ABI
changed and broke apps, it shoulda been bumped to libfoo.2). Most times
you can get away with not recompiling a port's dependants because
developers, but if you don't then it can shoot you in the foot (read the
recent list archives regarding openssl-0.9.8 to see an example of this).

Petersen



More information about the freebsd-questions mailing list