portversion recursive options

A

amnixed

Hello FreeBSD Experts,

I like to run portversion -vR before upgrading ports; sometimes it's a good idea to upgrade port A separately before upgrading port B, if port A is needed for building port B.

Now, that I need to upgrade png-1.4.8, I run portversion -vr to find out what are the ports which depend on png-1.* as /usr/ports/UPDATING informs us that upgrading png-1.4* to png-1.5* requires rebuilding all such ports. So:

Code: 
[root@doncurzio /usr/ports]# portversion -vr png-1.4.8
png-1.4.8                   <  needs updating (port has 1.5.13) 
[root@doncurzio /usr/ports]#

I'm sure I have ports installed which require png-1.*, for example:

Code: 
[root@doncurzio /usr/ports]# portversion -vR qt4-imageformats-4.7.4
...
pkgconf-0.8.9               =  up-to-date with port 
png-1.4.8                   <  needs updating (port has 1.5.13) 
python27-2.7.2_3            <  needs updating (port has 2.7.3_3) 
qt4-corelib-4.7.4           <  needs updating (port has 4.8.2) 
...
[root@doncurzio /usr/ports]#

Just what I thought.

Why does portversion -r not show the ports for which png-1.4.8 is required?

According to the man page the -R option is to "Check all packages required by the given packages as well."

What am I missing?
 
For a port that far back in UPDATING, what I'd do is start a small ledger (what ports break during the process); figure out which ports you use weekly that depend on png, and upgrade those with portmaster. That program should figure out what you should upgrade, for instance, during the following command if the upgrade question comes up "upgrade gcc?", you can decline, saving lots of compile time...
Code: 
portmaster -d -B -P -i -g www/firefox
, and most of the configuration questions should appear during the first ten minutes or so, although some may come unexpectedly later in the process. If you have PACKAGESITE set, possibly upstream packages exist which would make the upgrade even less time-consuming.
Sorry to not be answering the question though. Just a suggestion RE: the first introductory sentence in the post.
 
Use either ports-mgmt/portupgrade-devel or ports-mgmt/portmaster, but don't second-guess it.

You can (often) get an idea of the date of your last update with
% ls -ltr /var/db/pkg

First, check /usr/ports/UPDATING. Follow everything from the date of last update that affects your system.

After that, anything that is left over can be upgraded recursively. portmaster(8) makes sure that ports depended on are up to date, and then also updates anything depending on the port being updated. For example, it would check and upgrade anything that png depends on, then upgrade png, then upgrade anything that depends on png. (This is an example; png usually has explicit instructions in UPDATING.)

portupgrade(1) doesn't have the implicit actions that portmaster does, but has -r and -R options. Note that portmaster -a does not need either -r or -R.

Neither of these are foolproof, but if you pay attention to /usr/ports/UPDATING, it mostly works.
 
Thank you both for your replies.

wblock@ said:
[...]

portupgrade(1) doesn't have the implicit actions that portmaster does, but has -r and -R options.
Click to expand...

Right, and that's just my question, which I probably didn't ask very clearly first:

If
# portupgrade -r --noexecute png-1.4.8

reports that I have 139 ports which would be upgraded, then shouldn't

# portversion -r png-1.4.8

report at least as many ports depending on png-1.4.8 and that 139 of those could be upgraded?
 
No, I don't think so. portversion(1) is checking for version upgrades.

What the two programs are reporting is different:

Code: 
# portversion -r png

reports how many of the programs depending on png have new versions available.

Code: 
# portupgrade -nr png

reports how many programs will have to be rebuilt, whether they have new versions or not, if png is upgraded.
 
You must log in or register to reply here.
Back
Top