portversion oddities

The portversion command is part of the portupgrade port. I have it set to run from the daily periodic script so that I can see in the nightly e-mail if there are ports that need updating. ([cmd=]portversion -L =[/cmd] is the exact command in my script so that it doesn't include those ports that are already at the most recent version.) This has worked very well for several years.

However, there was an update done to portupgrade on November 8, which I happily updated. Starting that night, portversion no longer worked when run from cron. Instead, I get the following:

Code:
env: ruby: No such file or directory

# whereis ruby:
Code:
ruby: /usr/local/bin/ruby /usr/local/man/man1/ruby.1.gz


I figured that there was a problem with the link between the two, so I just waited. (This strategy has worked in the past much better than getting stressed out and spending lots of time trying to figure something out only to have it found and solved by somebody else whom I didn't know was working on it.) There was an update to ruby18 done on November 22, and another update to portupgrade on November 23. I installed both of these, but to no effect - portversion when run from cron still can't find ruby. I can run it from a root shell without any trouble though.


Another strangeness, which I don't know if it's related or not or even exactly when it started happening, is that when I run # portversion -L = from a command line when logged in as root, the database is rebuilt for all the ports every day. The ports tree is updated overnight via cron as well; in the past, only those ports that were changed were updated in the database, not all 22400+ ports every time. This part really isn't a big deal; if it runs from cron, it doesn't matter if it takes an extra 30 seconds to process. To me it's indicative of something semi-broken though; at least very different than behavior in the past. Given that it started about the same time as the above, it seems too coincidental for me not to mention.


Anybody have any ideas of what's going on or what I might do to fix this?
 
Put /usr/local/bin/ruby (so the full path) in your script or put PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin at the top of your crontab. See if that fixes the env error at least.
 
I added the PATH statement to the script in /usr/local/etc/periodic/daily that launches the portversion command, which I really should have thought of on my own. It seemed to fix the problem with not being able to find ruby when it ran last night, but still rebuilds the entire database every time. It's also curious that it never needed that before to find it, but not a big deal. Thanks DD!
 
This doesn't answer your question directly, but maybe you would prefer:

Code:
PATH=/usr/bin:/usr/sbin
portsnap -I cron update && pkg_version -v | grep -v =

You should basically get the same email as before, but this solution uses only base tools (assuming you are running a version with portsnap) and doesn't rely on external port databases.

Note, before you actually do the port upgrade(s) you'll have to do a portsnap update, or if you are sure you would never be messing with your ports tree when the job is running, you can remove the -I flag.

If you want to completely ditch the extra database portversion uses, you might like ports-mgmt/portmaster/.
 
I tried sending an e-mail to the port maintainer (ruby@freebsd.org) of portupgrade, but it bounced with a 'client host rejected: cannot find your hostname'. Dunno what that's all about - don't have trouble sending mail to anybody else. Maybe you could drop them a line and point them to this thread gohmdoree? I'm sure it's just a minor thing that was overlooked during the update...
 
Back
Top