Solved Updating port trough pkg?

Is it ok once you installed a ports or several of them to use pkg instead of portupgrade to update applications and programs?


Or doing so is gonna convert them back to binaries pkgs?
 
Ports typically means "i use git to create a source tree in /usr/ports and then do a make && make install". so Build from source.
pkg by default pulls binary packages from official FreeBSD repos.
Can you mix them? Sure but you may have problems unless you do things like lock something
I don't know the current wisdom on using "portupgrade" but it may (again I don't know for sure) be discouraged.
Ports source is now basically a git tree, so git clone, git pull, make install instead of portupgrade.

It's been a long time since I've built stuff from source, so I could be wrong
 
Ports typically means "i use git to create a source tree in /usr/ports and then do a make && make install". so Build from source.
pkg by default pulls binary packages from official FreeBSD repos.
Can you mix them? Sure but you may have problems unless you do things like lock something
I don't know the current wisdom on using "portupgrade" but it may (again I don't know for sure) be discouraged.
Ports source is now basically a git tree, so git clone, git pull, make install instead of portupgrade.

It's been a long time since I've built stuff from source, so I could be wrong
thank you, appreciate your help, I have read In the documentation that portupgrade will be abandonned soon pormaster is encouraged insteed
 
Is it ok once you installed a ports or several of them to use pkg instead of portupgrade to update applications and programs?
"It depends".

(omg, why am I now thinking about Kill Bill? Ahem, anywhoo...)

First things first: ports and packages? They're more or less the same thing. When you build a port? You're actually building a package which then gets installed using the standard methods ( # pkg install -f ./myPackage.pkg).

The possible culprit here are your build options. So: # make config, if these differ from the standard then you could run into a heap of trouble. And that's just mentioning the most obvious example... what about your port being build against (say) DB3 while the binary package used DB8?

No offense intended (!) but if you need to ask... then it's probably not a good idea to do this.

Generally speaking (!) => mixing ports and packages is bad.

Or doing so is gonna convert them back to binaries pkgs?
And this is why I said the above.

Ports build packages. Your binary packages are nothing more but pre-build packages which "other admins" made for your enjoyment and convenience. No more, no less.

Hope this could help!
 
" The possible culprit here are your build options. So: # make config, if these differ from the standard then you could run into a heap of trouble. And that's just mentioning the most obvious example... what about your port being build against (say) DB3 while the binary package used DB8?"

Ok just to be sure I'm correct, so once you do port install then no more pkg update && pkg upgrade, correct?
 
I've read it is various places including these forums, but an "official" example would be this:


Go down to Packaging section (right near the end):

ports-mgmt/portmaster has been removed as it has been discouraged in favour of using pkg and binary packages.

I think the context might be more about what's packaged on the DVD, but the overall "it has been discouraged" has been the message I've been seeing for a while.

I thought at one point it was definitely going to be removed from FreeBSD 14 (or maybe it was 15?) - so I've moved to binary packages (having to build rust and llvm was also pushing me away from portmaster/ports).

But looks like it is still around and had a couple of recent updates (but the first since 2024).

Poudriere seemed to be the "official" way to go but I just found it a lot more work than portmaster, so I've been using binary packages for the last six months or so.
 
I'm not sure what you are trying to do, but the advice is to choose to build from ports OR use pkg.

Depending on what you are installing, pkg will be x10 easier/faster than building from ports. Ports will give you a LOT more flexibility, but also the ability to make your life misery.

More and more ports are using rust, so one day you will end up pulling that in as a build dependency, and unless you have a grunty machine with lots of RAM you will not enjoy the experience.
 
Alternatives to portmaster are ports-mgmt/portupgrade and ports-mgmt/synth. Building from ports gives you finer control of what will be installed by using make config.

Example audio, if you install packages you wil have all audio backends (alsa, pulseaudio, sndio) installed as dependencies with them. These backends will cause trouble sooner or later. Port config options can prevent that from happening. I run all audio related stuff with base versions of oss and virtual_oss only.
 
I've read it is various places including these forums, but an "official" example would be this:


Go down to Packaging section (right near the end):

ports-mgmt/portmaster has been removed as it has been discouraged in favour of using pkg and binary packages.
I think that's old news. There was a small period where Portmaster didn't have a port maintainer and I believe that's when things started to turn towards port removal. However, nowadays it has a new maintainer and the script continues to work perfectly.

Been using ports-mgmt/portmaster for many years now and I don't see the point in using something else.
 
Now that I know installing from port I don't want to go back on binaries
I have a few custom ports that have different build options to those of the standard packages. I use Poudriere to compile them and create the corresponding binary packages that are saved on my private package repo for automatic distribution where needed. I haven't built a port locally on my workstation since I have been using Poudriere, which is probably ten years.
 
Is it ok once you installed a ports or several of them to use pkg instead of portupgrade to update applications and programs?
Did you set/unset options on those ports? If not, then there's really no point in building from ports in the first place. If you did customize the options then installing the package would 'reset' those. The packages in the FreeBSD repositories are all built with their default options.
 
Did you set/unset options on those ports? If not, then there's really no point in building from ports in the first place. If you did customize the options then installing the package would 'reset' those. The packages in the FreeBSD repositories are all built with their default options.
Some ports are not available as binary packages due to licensing issues.
 
Did you set/unset options on those ports? If not, then there's really no point in building from ports in the first place. If you did customize the options then installing the package would 'reset' those. The packages in the FreeBSD repositories are all built with their default options.
yes of coarse I did that's the whole point of using ports! and also have more recent software and patch
 
I don't see the point in using something else
The pain point for me was more things pulling in rust (or an older llvm) as a build dependency. I think there are ways around that (e.g. use pkg for installing rust) but at that point it felt too complicated and there was the push against portmaster. So I've moved to binary packages for now but good to know portmaster is still there if I need to go back to it.
 
The pain point for me was more things pulling in rust (or an older llvm) as a build dependency.
But that isn't something which Portmaster decides on its own, things like this happen because such environments are part of the build dependencies for some ports. Something which you can check for by running make build-depends-list. This is also why there are differences between build an run dependencies.

I think there are ways around that (e.g. use pkg for installing rust) but at that point it felt too complicated and there was the push against portmaster.
That's of course possible, but there's always a certain risk involved when you mix ports and packages.

But yah, this is actually one of the reasons why I decided to build myself some scripts to automate updating & upgrading with Portmaster. Portmaster has an option to ignore certain ports (using -x) and that's a good way to postpone certain updates if you don't want to immediately run them:

Code:
        # Check for ports to ignore.
        for a in $(cat $CONF | grep -e '^ignore' | cut -d '=' -f2-); do
                if [ ! -z $a ]; then IGNORE="$IGNORE -x $a"; fi
        done;

<snip>

build() {
        portmaster -a $IGNORE\
        | tee $LOG
}
 
Back
Top