What's the current procedure for maintaining ports and packages up to date

r00ty

r00ty

Hey everyone,


I've been using FreeBSD since version 3 - started way back in the day at a company I used to work for, long before poudriere was a thing.
These days, I just maintain a couple of personal servers running FreeBSD 14.1, each on a different architecture.

Historically, I've kept my ports up to date using the following steps:
  1. portsnap fetch update
  2. portupgrade package
    or I'd manually cd /usr/ports/category/port and build from there when I needed specific options.
I’ve always preferred building from ports because many of my packages have custom build options, so I rarely use pkg install.

I've already switched to using Git for managing the ports tree, but I have a couple of questions:
  • Portsnap used to build the INDEX file automatically. Is it enough to run make -C /usr/ports index after a git pull, or is there more I should be doing?
  • What’s the best modern replacement for portupgrade? I tried portmaster, but it ended up in a wild infinite dependency loop, rebuilding and reinstalling the same packages over and over. I let it run overnight, and it was still going in the morning.

Would appreciate any help, thanks!
 
r00ty said:
I've already switched to using Git for managing the ports tree, but I have a couple of questions:
  • Portsnap used to build the INDEX file automatically. Is it enough to run make -C /usr/ports index after a git pull, or is there more I should be doing?
  • What’s the best modern replacement for portupgrade? I tried portmaster, but it ended up in a wild infinite dependency loop, rebuilding and reinstalling the same packages over and over. I let it run overnight, and it was still going in the morning.
Click to expand...
First, I know it sounds cliche, but "best" really is in the eye of the beholder. Some people use build targets manually as they're laid out in ports(7) whereas others rely on frameworks like, say, ports-mgmt/poudriere.

I myself still fully rely on Portmaster (+ a set of scripts I developed to help me out) and I can rest assure you that if you're suffering from dependency loops then that's not caused by Portmaster, but most likely by some port dependencies which you haven't pinned down to a specific version yet (see /usr/ports/Mk/bsd.default-versions.mk and/or /etc/make.conf).

But anyway... INDEX... I scripted the whole thing myself but yes, after issuing git pull you'll need to perform a manual build index if you care for that. I'm also aware of the fetchindex target (like I said: see the ports(7)) but I can't comment on it since I never used it myself. Still... theoretically (!) that's also an alternative and it's likely going to be a lot quicker than having to build the whole index yourself. Assuming that it does what I expect ;)

Keep in mind though that unless you actively use # make search ... then there's no direct need for those indexes.

As for building ports.. once again.. take your pick... I'm aware of Poudriere and I also recall Synth, but have no experience with either of those, Portmaster still works excellent for me.

Hope this can give you some ideas.
 
Sorry for a 'double post' but I just realized that I forgot to mention something very important, so instead of editing I figured I might as well comment again; you asked about the "current procedure" afterall. I know this is also well documented, who cares. You asked, I answered and then I'd better make it right! ;)

What is the current (general) procedure for using the ports collection?
  1. Keep your ports up to date (obviously) => git pull /usr/ports origin/main. (<== fixed typoe! thanks POSIX.1 !).
  2. Always check with /usr/ports/UPDATING to see if there are specific issues to address with your upgrades / updates *
  3. Briefly check /usr/ports/CHANGES to check if there are sudden difference in changes on how some ports work and/or behave.
  4. When in doubt: also check /usr/ports/MOVED to check if a port got removed ("expired") or maybe renamed?
  5. Make yourself familiar with basic ports administration, even if you're using a framework (start with ports(7)). Personal (!) reasoning: when things go really bad... are we sure it's the ports themselves or could the framework have anything to do with it? One way to find out!

* There's a reason for my comment obviously:
/usr/ports/UPDATING said:
20250402:
AFFECTS: users of devel/glib20 and devel/gobject-introspection building outside of Poudriere
AUTHOR: arrowd@FreeBSD.org
New versions of glib started to require gobject-introspection as a build dependency, while gobject-introspection requires glib to build. This forms a dependency cycle that is dealt with by introducing the @bootstrap flavor for mentioned ports. This solution is suggested by the upstream as well, see
Click to expand...
So yeah, this could theoretically also have been a cause for your issues, so I figured I'd mention it.

Fun fact: The reason I initially overlooked this is because... Portmaster also had 0 issues with any of it. I was checking UPDATING today to address another (self-inflicted!) "problem" I'm having when I noticed the above and recalled your question. So I figured I should post a brief update.
 
I do use Poudriere but I never needed a built INDEX in Poudriere's ports-tree, but I love to have a reasonably updated INDEX unter /usr/ports/ for ports-mgmt/psearch which I get with this script:
sh: 
#!/bin/sh
#
# Fetch the FreeBSD port index
#

os_version_major=`uname -r | cut -c 1,2`
index="INDEX-$os_version_major"

if [ ! -e /usr/ports ]; then
    mkdir -p /usr/ports
fi

cd /usr/ports
if [ -e /usr/ports/$index.xz ]; then
    # fetch -i fetches only if there is a newer file than that we have
    fetch -i $index.xz https://download.FreeBSD.org/ports/index/$index.xz
else
    fetch https://download.FreeBSD.org/ports/index/$index.xz
fi

# if we fetched a new file, remove the old INDEX file before extracting xz
if [ $? == 0 ]; then
    rm .fetch* $index 2> /dev/null    # clean up .fetch.* files
    unxz -k $index.xz
else
    exit
fi
 
At $JOB I use binary packages in VMs that themselves are updated using freebsd-update (13 and 14 -RELEASE). It's binary only there, because I don't have the time to maintain FreeBSD ports and src using the build everything approach.

At $HOME I have my own poudriere because I use 15-CURRENT here. I'm a developer. I eat my own dogfood.

If I wasn't a developer I'd use binary packages everywhere (src & ports) and focus my time and energy somewhere else. The younger me would have disagreed because UNIX was new to the younger me. I've been using UNIX, Linux, and FreeBSD for longer than I had been working on IBM mainframe. It's different now. I look for shortcuts to get each job done as quickly as possible. And building form sources if I don't have to is fine by me. When I retire professionally and from FreeBSD I will certainly go the binary packages only approach.
 
cy@ said:
I'd use binary packages everywhere (src & ports) and focus my time and energy somewhere else.
Click to expand...
Yeah! Building from source/ports is a waste of resources unless you have a good reason for doing so, like enabling a non-default port option, or getting a patched CVE version for security reasons earlier than from the package repo some days later.
 
POSIX.1 said:
Hmm, obviously the ports-tree is and should not be there: /usr/src/.
Click to expand...
Thank you very much for that, really appreciate it.. Yah, that's the result of doing an allnighter while fixing some missed dependencies in the kernel modules ("MODULES_OVERRIDE") and experimenting with including & removing acpi / hid.

No excuse, obviously; that was stupid of me.
 
Keep in mind though that unless you actively use # make search ... then there's no direct need for those indexes.
Click to expand...
I mostly use the INDEX just to speed up pkg version -vL= - otherwise it takes ages to run.

Quick question, have you ever run into those dependency loop issues with Portmaster? How do you usually troubleshoot them? I mean, aside from checking the UPDATING, CHANGES, and MOVED files.
 
You must log in or register to reply here.
Back
Top