Rebuilding all ports with portmaster

wblock@

Developer
This is the updated procedure to rebuild all ports with ports-mgmt/portmaster:

1. portmaster --list-origins > ~/installed-port-list
2. Update the ports tree
3. portmaster -ty --clean-distfiles
4. portmaster -Faf
5. pkg delete -afy
6. rm -rf /usr/local/lib/compat/pkg
7. Back up any files in /usr/local you wish to save, such as configuration files in /usr/local/etc
8. Manually check /usr/local and /var/db/pkg to make sure that they are really empty
9. Install ports-mgmt/pkg and then ports-mgmt/portmaster. Remove both from ~/installed-port-list.
10. portmaster --no-confirm `cat ~/installed-port-list`

This is, in fact, faster and less likely to have problems than portmaster -af.
 
Not exactly. The current man page is outdated and still has instructions for the old package system. This version is updated and tested for pkg(8). It was submitted as a PR: PR 191166.
 
Thanks for this. I tested the procedure on my 1 GHz single-core machine running 10.2-STABLE, with a handful* of ports installed, and it indeed was 30% faster than portmaster -af (not counting the time to portsnap fetch update and delays when I was AFK).

Here are a few comments—not criticisms, just trying to be helpful:

In step 8, I realize it's what the original man page said, but it seems one shouldn't expect /usr/local to be totally empty. It just should no longer contain files added by ports. It will still contain any independently created files, such as /usr/local/man/whatis (database used by whatis) and config files you created yourself.

It seems /var/db/pkg will not be empty, either, but rather will still contain a directory for each package, with a distfiles file in each one. The only things removed will be local.sqlite and vuln.xml.

The second part of step 9, remove both from ~/installed-port-list, could be done like this:
sed -I '' -E '/^ports-mgmt\/(pkg|portmaster)$/d' ~/installed-port-list

Is it necessary to say "Install ports-mgmt/pkg and then ports-mgmt/portmaster"? I ask because if you just install ports-mgmt/portmaster, you get ports-mgmt/pkg because it is a dependency. (Or is that not always true?)


* portmaster, fusefs-ext4fuse, nano, and opensmtpd ... plus their dependencies: autoconf, autoconf-wrapper-*, automake, automake-wrapper-*, dialog4ports, expat, fusefs-libs, gettext-runtime, gettext-tools, gmake, gmake-lite, help2man, indexinfo, libasr, libevent2, libexecinfo, libtool, m4, openssl, perl5, p5-Locale-gettext, pkg, pkgconf.
 
That part about /usr/local being empty has always kind of bugged me also. But yes, it was an effort to stick to the original text.

Yes, sed or other programs could be used to remove those entries, but what is being done is not as apparent.

It's kind of the same thing with saying to install both ports-mgmt/pkg and ports-mgmt/portmaster. What is happening is more obvious that way. Because this is a set of steps rather than a script, being explicit helps the user understand what is going on.
 
I'm looking to upgrade ~950 ports on a box tracking -CURRENT I just updated. I don't suppose this method will honour the options already chosen, and stored in /var/db/ports/* ? Even without the --no-confirm ?

Thanks!

--Chris
 
I'm looking to upgrade ~950 ports on a box tracking -CURRENT I just updated. I don't suppose this method will honour the options already chosen, and stored in /var/db/ports/* ? Even without the --no-confirm ?
For poudriere you can copy them from /var/db/ports/* to /usr/local/etc/poudriere.d/<jail-name>-options/.

portmaster(8) should honor the options that are already set.
 
Thanks, SirDice . Just the reassurance I was looking for! :) This is my package builder. I currently use "traditional" jails to build kernels, and packages for the STABLE_9 boxes I have. But in the process, I let this one fall behind. Of course now, if something goes awry for me. It's on you. ;)

Oooo. something shiny...

Hello marino@! I had never heard of ports-mgmt/synth before, and made by you no less. I'm going to give it a go. It looks like exactly what I'm looking for. You've never steered me wrong before. Thanks!

and to any onlookers; always be sure you have fresh dump()s before making any major changes! :)

--Chris
 
So I have a silly question about the original post by wblock@: this method deletes and rebuilds all installed ports, which I understand. Having recently moved to ports only, I was hoping to not have to rebuild everything, every time after I run portsnap fetch update. I have been doing the following instead:


portmaster -L | egrep -B1 '(ew|ort) version|Aborting|installed|dependencies|IGNORE|marked|Reason:|MOVED|deleted|exist|update' | grep -v '^--'


Then portmaster -a

This has been working perfectly to rebuild only the things that are updated when I refresh the ports tree (to include deps). Is this a good process or should I be rebuilding all ports every update?
 
So I have a silly question about the original post by wblock@: this method deletes and rebuilds all installed ports, which I understand. Having recently moved to ports only, I was hoping to not have to rebuild everything, every time after I run portsnap fetch update. I have been doing the following instead:

portmaster -L | egrep -B1 '(ew|ort) version|Aborting|installed|dependencies|IGNORE|marked|Reason:|MOVED|deleted|exist|update' | grep -v '^--'

Then portmaster -a

This has been working perfectly to rebuild only the things that are updated when I refresh the ports tree (to include deps). Is this a good process or should I be rebuilding all ports every update?
My ports tree gets updated via svn, but usually I just run portmaster -a -d after updating it by means of make -C /usr/ports update fetchindex.
 
Yeah, the long call to portmaster just shows me what is going to get updated but I guess I really don't need it because portmaster tells me anyway what it is going to do...thanks for the info! Some things aren't obvious sometimes until someone else points them out 😉
 
I'm a little bit disappointed to see experienced sysadmins promoting a build tools that is proven to be broken by design. Please do the less experienced users a favour and instead advise them to use ports-mgmt/poudriere or ports-mgmt/synth, and build on the main machine (not in a jail) only for ports which have very limited set of dependencies or none at all (there are some scripts in the ports).
 
I'm a little bit disappointed to see experienced sysadmins promoting a build tools that is proven to be broken by design. Please do the less experienced users a favour and instead advise them to use ports-mgmt/poudriere or ports-mgmt/synth, and build on the main machine (not in a jail) only for ports which have very limited set of dependencies or none at all (there are some scripts in the ports).
Maybe is broken by design, I do not know but I know that I ddidn't have many problems from FreeBSD 6.?. I had to use Synth for short time but it is so painful to build so many ports and I do not have a server and I belive that are many users which use FreeBSD as a desktop machine as I use. And the lua version looks much better.
 
I'm a little bit disappointed to see experienced sysadmins promoting a build tools that is proven to be broken by design.

It got us this far.
no thanks to prefect by miopic opinion
keep the diversity
thank you for your contributions
my opinions are my own
 
Back
Top