Is there a BEST way to update ports?

G

ghostcorps

Hi Guys

I have been looking into ways to keep my system upto date and have gotten myself a bit turned around.

To update my port tree I have this in my crontab:


Code: 
portsnap -I cron update && pkg_version -vIL=

Which sends me an email advising that there are ports to update. However I have found at least three ways to do the update, each of which seems to have their own pros and cons.


The best options I have found so far are:

Code: 
portupgrade -aRrP

Code: 
portmanager -u -l

Code: 
portmaster -ay

Or this script:

Code: 
#!/bin/sh
/usr/sbin/portsnap fetch update && \
/usr/local/sbin/portmaster -L --index-only | egrep '(ew|ort) version|total install'

Or this script: http://www.mebsd.com/freebsd-security-hardening/update-freebsd-with-portmaster.html

I know there are alot of opinions in the forum and portmaster looks to be the method of choice but is there any reason to think otherwise? I have run portmanager already, will it preclude using the portmaster next time?

Thanks :)
 
For the part of vermaden's post about updating applications, it's using packages. Packages are just precompiled ports, off-the-rack "one size fits all" binaries. Since they're already compiled, that step is skipped, saving time. Differences between the FreeBSD package build cluster and the target system can cause problems.
 
wblock said:
For the part of vermaden's post about updating applications, it's using packages. Packages are just precompiled ports, off-the-rack "one size fits all" binaries. Since they're already compiled, that step is skipped, saving time. Differences between the FreeBSD package build cluster and the target system can cause problems.
Click to expand...

So you are saying that using Packages as in Vermadens method is quicker but it can cause problems in systems that are not exactly standard?
 
ghostcorps said:
So you are saying that using Packages as in Vermadens method is quicker but it can cause problems in systems that are not exactly standard?
Click to expand...

The package cluster machines build packages in a set environment. Usually that will have the latest libraries and such. Download one of those packages onto a machine that has older libraries, and it will complain. That can cascade into a bunch of upgrades.

Ports don't have that particular problem, since they're built on the target machine.
 
@wblock

That is why I also use from time to time ports-build function from my howto to cope with such problems, so far, I haven't seen any of them, but the longer You would not update the base system, the bigger chance for hitting such problems, that is why I included information about updating the base system in the first part.

The only 'problem' are options that are (or not) compiled into the packages, for example like lack of TTF support in conky which I must rebuild (with ports-build function) every time the new version is fetched, but its harmless.

I found that way the least problematic and time consuming, pity we do not have 'stable ports tree' but that has been discussed many times that FreeBSD community does not currently have man power to do that.
 
Thanks guys :)

I think I will stick with the simpler method. It is a new build and is not 100% upto date.

Since I do like to tinker though, I think I should stick with the method that to me seems more straightforward and more forgiving to any hacks I may need to make in the future.

Thanks again :)

Have a great day.
 
wblock said:
Forgot to mention this from post #1. -arR, sometimes called "pirate mode", is equivalent to -a.
Click to expand...

hahaha that's exactly how I would say it in my mind! :)


carlton_draught: Dutchdemons script is very nice thankyou :)
 
Dumb question I know. But I haven't used crontab very often.

I have this in /etc/crontab

Code: 
@daily                                  root    portupdater.sh cron

Is this correct? The script is in /usr/bin
 
You might need to specify a PATH with something like:

Code: 
PATH=/bin:/sbin:/usr/bin:/usr/sbin

or specify the whole path for the command, i.e., /usr/bin/portupdater.sh.
 
Thanks :)

/etc/crontab already shows /usr/bin in the PATH. I originally had the script in / and specified the whole path, but I thought I should keep it neat and put the script where crontab expects it to be so I moved it.

Thanks again :)
 
One thing ghostcorps - I would recommend running that script manually as it asks for input from time to time, to delete various things as necessary. Unless DutchDaemon says otherwise, I would not put it in crontab.
 
Thanks for the followup Carlton,

In the post you sent me to DutchDaemon advises that the script be run from /etc/crontab, but that it can be run manually without interaction using portupdater yes or portupdater now which allows the interactive options.

I have confirmed that manually running portupdater cron does not require interaction either.
 
One problem with automated updating of ports is that by the time you see the special procedures in /usr/ports/UPDATING, the system may already be broken.
 
wblock said:
One problem with automated updating of ports is that by the time you see the special procedures in /usr/ports/UPDATING, the system may already be broken.
Click to expand...

Thanks for the heads up,

I have been reading /usr/ports/UPDATING after running the script but before portmaster -a which I do manually. Is this still too late?

DutchDaemon said:
The script will only update/maintain the ports tree and show a summary, it will not update ports.
Click to expand...
 
ghostcorps said:
Thanks for the heads up,

I have been reading /usr/ports/UPDATING after running the script but before portmaster -a which I do manually. Is this still too late?
Click to expand...

No that, should be okay.
 
Cool :) Thanks again

Now I just need to figure out why freebsd-update cron is isn't sending me mail and the update procedure is done. :)
 
I'm just going to state this once again, as if I haven't done this often enough:

Leave /etc/crontab alone.

It is the system's crontab and may be altered or overwritten in an OS upgrade. Put cron jobs for root (or any user) in their own personal crontab, which is available by running [cmd=]crontab -e[/cmd] as that particular user. Note that you will not need the 'user field' in that case, because the crontab is already personal.

crontab(5)
 
You must log in or register to reply here.
Back
Top