pkg_version & notification when port needs manual attendance

H

hansaplast

I want to automagically update all ports (/usr/sbin/pkg_version -l "<") which do not exist in /usr/ports/UPDATING prior to my last update.

Is there a tool which does that or should I write the script myself? It would also be handy if the tool notifies root if a port exists in UPDATING.
 
vivek said:
Plenty of tools can do that. Use ports-mgmt/portmaster/
Code: 
portmaster -a
Click to expand...
Thank you.

Using the option "-u" enables unattended mode. Reading through the manual it exits when a when a port has "CONFLICTS" set. Do all relevant ports in /usr/ports/UPDATING have "CONFLICTS" set?

To put it in another way. Can you rely on "portmaster -au" in a cron job?
 
Noop.

Running ports update from cron is a bad idea. Something may go wrong. For e.g. many services (such as dovecot, spamAssassin and others) are stopped while updating but they are not started after update. Some services may need to run additional scripts or update configuration files.

I recommend you use screen and start the procedure and de-attach the session. Come back later and see the logs. Another option is to log everything to a log file and review it the same for error and update info.

HTH
 
vivek said:
Noop.

Running ports update from cron is a bad idea.
Click to expand...
Why is this a bad idea?
If a service needs manual intervention it must be placed in /usr/ports/UPDATING. If it needs a restart after update, you can (automatically) restart or signal the process (not that hard to implement). There are several other situations in which you need to do something extra. Like setting rights on files after updating the clam daemon. This also can be scripted. If the program needs some configuration change during an update, just put it in UPDATING.

Wouldn't it be nice if there was a tool in which you can finetune the automated update process. A lot of it is just standard stuff. Only sometimes you need to intervene manually.
I don't understand why this is a *bad* idea.
 
hansaplast said:
I don't understand why this is a *bad* idea.
Click to expand...
It couldn't be bad, if you don't mind about getting new ports bugs before other people and before there is a solution/workaround ready.
Consider also that some ports require to manually force the rebuild of the forward dependencies, a new port may want to pull in unwanted dependecies,... and so on.
 
hansaplast said:
I don't understand why this is a *bad* idea.
Click to expand...
ale is right. Some updates may break things and it will happen; you do not want to take such responsibility for a production box.
 
vivek said:
ale is right. Some updates may break things and it will happen; you do not want to take such responsibility for a production box.
Click to expand...
This too can be solved using a stable and unstable branch for the ports. Creating a program which monitors the (un)successful building process can give you stats which can be used to put unstable ports into the stable branch (mind, the reverse is also possible)

I'm sure this dialogue isn't the first one regarding this topic. It is my opinion that a lot of it can and should be automated using the right concept and tools. However, this shouldn't be discussed here ;)

Best regards,

Hansa
 
hansaplast said:
Creating a program which monitors the (un)successful building process can give you stats which can be used to put unstable ports into the stable branch (mind, the reverse is also possible)
Click to expand...

http://pointyhat.freebsd.org/errorlogs/

Packages are build automatically but they're not installed. You could setup a jail, build your packages and be done. The installing would need to be done by hand once you've read UPDATING.
 
You must log in or register to reply here.
Back
Top