Completely Removing a package

Installed 14.2 on my laptop; now configuring. I decided to use "ports" exclusively after I had installed several "packages". I deleted the packages but it seems to me that doing so does not completely remove the package. I suspect that because when I subsequently installed the port version of the application, the process went too quickly and I wasn't prompted for "stuff".

Is there a method to completely remove a package as if it never happened? TIA
 
pkg remove completely removes packages. The only thing it doesn't touch is configuration files (and, if applicable, files that aren't part of the package but created by the software, like some stuff below /var)
 
Shoot! I did `pkg delete <name>' thinking that had to be the way to go. I should have RTFM a little better! Thanks
 
pkg-remove(8) and pkg-delete(8) are the same thing (remove is an alias for delete). But yes, somethings aren't removed (or deleted).

Note that there's effectively no difference between a port and a package. A port builds a package, a package is nothing more than a pre-compiled port. If you don't change options (or change the defaults, like a different Python or MySQL version) then there's really no reason to build from ports.
 
pkg-remove(8) and pkg-delete(8) are the same thing (remove is an alias for delete). But yes, somethings aren't removed (or deleted).

Note that there's effectively no difference between a port and a package. A port builds a package, a package is nothing more than a pre-compiled port.
Thanks for clarifying!
But are not ports updated more frequently than packages?

I can't remember if it was emacs or Xorg that I originally installed from pkg, but after I did e.g. pkg delete Xorg and then ran portmaster to install it again, I never was prompted for anything like usually happens when you cd to the port and do a make install clean. Just wondering where I blew it!!
 
But are not ports updated more frequently than packages?
No. Ports are continuously updated in the "head" branch, and there's a "quarterly" branch (every quarter) branched off head that only receives important fixes. There are official package repositories built from both of them.

As the builders need some time, a package will typically be available a few days after the port in the respective branch was updated.
ran portmaster to install it again, I never was prompted for anything like usually happens
Are you talking about the build options for the port? You're only asked automatically once and your configuration is saved to /var/db/ports. If you want to see this dialog again, you have to run make config. (BTW, for portmaster(8), there's --force-config)

pkg doesn't write port configs (and official packages are always built with default options). So if you don't see this, you have built the port on that machine before.
 
No. Ports are continuously updated in the "head" branch, and there's a "quarterly" branch (every quarter) branched off head that only receives important fixes. There are official package repositories built from both of them.

As the builders need some time, a package will typically be available a few days after the port in the respective branch was updated.

Are you talking about the build options for the port? You're only asked automatically once and your configuration is saved to /var/db/ports. If you want to see this dialog again, you have to run make config. (BTW, for portmaster(8), there's --force-config)

pkg doesn't write port configs (and official packages are always built with default options). So if you don't see this, you have built the port on that machine before.
Thanks for the info! I was/am following a FBSD Forum post from 2017 which walks through the FBSD install process. It recommended to use and stick with either ports or pkg, but not to mix them. The author also suggested that ports software was more "up-to-date".
 
Are you talking about the build options for the port? You're only asked automatically once and your configuration is saved to /var/db/ports. If you want to see this dialog again, you have to run make config. (BTW, for portmaster(8), there's --force-config)
Exactly! BUT I had never installed the software from ports. Instead I had used pkg. When I removed the software with pkg delete, and then re-installed using ports, the build options never showed up like they would with a fresh, first-time installation of whatever software.
 
Mixing ports and packages is perfectly possible, but not recommended because it requires extra care (and: knowing what you do) to get it right.

The most important thing about it: The packages you use must come from a repository built from the branch of ports you're using to build your own. On a fresh install, pkg is configured to use a quarterly repository, while the portsnap(8) tool will always fetch a recent snapshot of the head branch (which is used to build the latest repository). Mixing this is recipe for desaster.

Exactly! BUT I had never installed the software from ports. Instead I had used pkg. When I removed the software with pkg delete, and then re-installed using ports, the build options never showed up like they would with a fresh, first-time installation of whatever software.
Sorry, but that's just impossible. Check in /var/db/ports. pkg will never put anything there.
 
Mixing ports and packages is perfectly possible, but not recommended because it requires extra care (and: knowing what you do) to get it right.

The most important thing about it: The packages you use must come from a repository built from the branch of ports you're using to build your own. On a fresh install, pkg is configured to use a quarterly repository, while the portsnap(8) tool will always fetch a recent snapshot of the head branch (which is used to build the latest repository). Mixing this is recipe for desaster.


Sorry, but that's just impossible. Check in /var/db/ports. pkg will never put anything there.
I'm going to get back to you/this thread later on. I'm not on my FBSD box at the moment and can't remember what I did and the steps I did it in.
 
-RELEASE versions default to using the quarterly package repositories, -STABLE defaults to latest. Either system can be switched to latest or quarterly if desired. All you need to do is create a /usr/local/etc/pkg/repos/FreeBSD.conf with:
Code:
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
}

When I removed the software with pkg delete, and then re-installed using ports, the build options never showed up like they would with a fresh, first-time installation of whatever software.
Build options are, ehm, build time options. Packages don't get built, they are already built. So why would a package store build options? That said, you can actually see which options a package was built with by looking at pkg-info(8):
Code:
root@molly:~ # pkg info tmux
tmux-3.1c
Name           : tmux
Version        : 3.1c
Installed on   : Sun Jan 31 22:20:48 2021 CET
Origin         : sysutils/tmux
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : sysutils
Licenses       : ISCL
Maintainer     : mat@FreeBSD.org
WWW            : http://tmux.github.io/
Comment        : Terminal Multiplexer
Options        :
        BACKSPACE      : off
        DOCS           : on
        EXAMPLES       : on
        LIBEVENT_STATIC: off
        UTF8PROC       : off
Shared Libs required:
        libevent-2.1.so.7
Annotations    :
        FreeBSD_version: 1300136
        repo_type      : binary
        repository     : dicelan-server
Flat size      : 815KiB
Description    :
Tmux is a terminal multiplexer, it enables a number of terminals to be accessed
and controlled from a single terminal. tmux is intended to be a simple, modern,
BSD-licensed alternative to programs such as GNU screen.

WWW: http://tmux.github.io/
Take a look at the "Options" section, these correspond with the port's options:
Code:
root@molly:/usr/ports/sysutils/tmux # make showconfig
===> The following configuration options are available for tmux-3.1c:
     BACKSPACE=off: Build with tty/keys patch
     DOCS=on: Build and/or install documentation
     EXAMPLES=on: Build and/or install examples
     LIBEVENT_STATIC=off: Build with static libevent
     UTF8PROC=off: Build with utf8proc support
===> Use 'make config' to modify these settings

For ports, read ports(7). A make config stores the set options in /var/db/ports/:
Code:
root@molly:/usr/ports/sysutils/tmux # make config

root@molly:/usr/ports/sysutils/tmux # ls -al /var/db/ports/sysutils_tmux/
total 11
drwxr-xr-x  2 root  wheel    3 Mar 26 16:47 .
drwxr-xr-x  5 root  wheel    5 Mar 26 16:47 ..
-rw-r--r--  1 root  wheel  318 Mar 26 16:47 options
root@molly:/usr/ports/sysutils/tmux # cat /var/db/ports/sysutils_tmux/options
# This file is auto-generated by 'make config'.
# Options for tmux-3.1c
_OPTIONS_READ=tmux-3.1c
_FILE_COMPLETE_OPTIONS_LIST=BACKSPACE DOCS EXAMPLES LIBEVENT_STATIC UTF8PROC
OPTIONS_FILE_UNSET+=BACKSPACE
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_SET+=EXAMPLES
OPTIONS_FILE_UNSET+=LIBEVENT_STATIC
OPTIONS_FILE_UNSET+=UTF8PROC
root@molly:/usr/ports/sysutils/tmux #

On FreeBSD everything starts with a port, there won't be a package if there is no port. So the port is always updated first. In this sense the ports tree is always more up to date. But once a port has been updated various automated processes kick into gear and start building packages. As you can imagine building 43000+ packages for various different FreeBSD versions and architectures will take some time. Then those built packages need to be distributed to the various mirrors, which also takes some time. So even the latest package repositories will lag behind a little. You can keep track of those automated builds here: https://pkg-status.freebsd.org/

If you really want the latest and greatest as soon as it's available in the ports tree, then set up your own repository. This is actually quite easy to do, the process is completely automated, all you need is ports-mgmt/poudriere or ports-mgmt/synth and a lot of resources (time, RAM, CPU power and storage). You don't need to build everything, you can tell both tools to only build what you need, they'll figure out what else is required (dependencies and such). The biggest advantage of having your own repository is that you're not depending on the official repositories. You can set your own defaults (different default Python or PHP version, MariaDB instead MySQL etc) and options. And use your own update strategy (when, where and what to update).
 
-RELEASE versions default to using the quarterly package repositories, -STABLE defaults to latest. Either system can be switched to latest or quarterly if desired. All you need to do is create a /usr/local/etc/pkg/repos/FreeBSD.conf with:
Code:
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
}


Build options are, ehm, build time options. Packages don't get built, they are already built. So why would a package store build options? That said, you can actually see which options a package was built with by looking at pkg-info(8):
Code:
root@molly:~ # pkg info tmux
tmux-3.1c
Name           : tmux
Version        : 3.1c
Installed on   : Sun Jan 31 22:20:48 2021 CET
Origin         : sysutils/tmux
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : sysutils
Licenses       : ISCL
Maintainer     : mat@FreeBSD.org
WWW            : http://tmux.github.io/
Comment        : Terminal Multiplexer
Options        :
        BACKSPACE      : off
        DOCS           : on
        EXAMPLES       : on
        LIBEVENT_STATIC: off
        UTF8PROC       : off
Shared Libs required:
        libevent-2.1.so.7
Annotations    :
        FreeBSD_version: 1300136
        repo_type      : binary
        repository     : dicelan-server
Flat size      : 815KiB
Description    :
Tmux is a terminal multiplexer, it enables a number of terminals to be accessed
and controlled from a single terminal. tmux is intended to be a simple, modern,
BSD-licensed alternative to programs such as GNU screen.

WWW: http://tmux.github.io/
Take a look at the "Options" section, these correspond with the port's options:
Code:
root@molly:/usr/ports/sysutils/tmux # make showconfig
===> The following configuration options are available for tmux-3.1c:
     BACKSPACE=off: Build with tty/keys patch
     DOCS=on: Build and/or install documentation
     EXAMPLES=on: Build and/or install examples
     LIBEVENT_STATIC=off: Build with static libevent
     UTF8PROC=off: Build with utf8proc support
===> Use 'make config' to modify these settings

For ports, read ports(7). A make config stores the set options in /var/db/ports/:
Code:
root@molly:/usr/ports/sysutils/tmux # make config

root@molly:/usr/ports/sysutils/tmux # ls -al /var/db/ports/sysutils_tmux/
total 11
drwxr-xr-x  2 root  wheel    3 Mar 26 16:47 .
drwxr-xr-x  5 root  wheel    5 Mar 26 16:47 ..
-rw-r--r--  1 root  wheel  318 Mar 26 16:47 options
root@molly:/usr/ports/sysutils/tmux # cat /var/db/ports/sysutils_tmux/options
# This file is auto-generated by 'make config'.
# Options for tmux-3.1c
_OPTIONS_READ=tmux-3.1c
_FILE_COMPLETE_OPTIONS_LIST=BACKSPACE DOCS EXAMPLES LIBEVENT_STATIC UTF8PROC
OPTIONS_FILE_UNSET+=BACKSPACE
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_SET+=EXAMPLES
OPTIONS_FILE_UNSET+=LIBEVENT_STATIC
OPTIONS_FILE_UNSET+=UTF8PROC
root@molly:/usr/ports/sysutils/tmux #

On FreeBSD everything starts with a port, there won't be a package if there is no port. So the port is always updated first. In this sense the ports tree is always more up to date. But once a port has been updated various automated processes kick into gear and start building packages. As you can imagine building 43000+ packages for various different FreeBSD versions and architectures will take some time. Then those built packages need to be distributed to the various mirrors, which also takes some time. So even the latest package repositories will lag behind a little. You can keep track of those automated builds here: https://pkg-status.freebsd.org/

If you really want the latest and greatest as soon as it's available in the ports tree, then set up your own repository. This is actually quite easy to do, the process is completely automated, all you need is ports-mgmt/poudriere or ports-mgmt/synth and a lot of resources (time, RAM, CPU power and storage). You don't need to build everything, you can tell both tools to only build what you need, they'll figure out what else is required (dependencies and such). The biggest advantage of having your own repository is that you're not depending on the official repositories. You can set your own defaults (different default Python or PHP version, MariaDB instead MySQL etc) and options. And use your own update strategy (when, where and what to update).
Thanks for the comprehensive reply. It's all the same to me whether I use ports or package OR FreeBSD for that matter.

I have the antiX Linux distro on the first half of my HDD.
I set up FreeBSD for no other reason than as yet another learning experience. I don't need it for anything. I'm following this forum post:
https://forums.freebsd.org/threads/...-set-up-a-freebsd-desktop-from-scratch.61659/

If ports is the way to go - I'm all for it.
If using pkg makes more sense - that's what I'll do.
I'm all for keeping it simple!

So maybe I'll simply re-install 14.2 and start fresh using pkgs and be done with it! Or maybe I'll just say "pluck it!" ......

Thanks for your input!
 
You keep talking about 14.2, which is a release from the future :-/

To "keep it simple", use packages.

---
14 just started as 14-CURRENT and has a LONG way to become 14.0-RELEASE eventually
13 is at -RC3-p1 right now and will become 13.0-RELEASE in a week (hopefully)
12 is at 12.2-RELEASE
11 is at 11.4-RELEASE
 
That would be mine.

I used ports in my Tutorial because that was all I'd ever used til recently and the thought of using pkg didn't even occur to me. You can read what I thought were the Pros and Cons and decide for yourself.

It's much faster to use pkg but are you going to know how to fix that vulnerability I found if you've never used ports? It was pretty easy but that's my take on it and I may have overestimated a user to usr in average ability. Natures Way takes care of that sort of thing and those people will rise to the occasion or this is too much for them and it will soon become apparent.

That's why I advise to use one or the other. You may run into problems you don't yet have the experience to solve and succumb to frustration when it could have been avoided. But I am a proponent of Natures Way.

You're a Linux usr so that doesn't apply to you personally, I'm speaking in general terms. Using nothing but ports gave me valuable experience in solving those issues and I think you're missing out on a big part of FreeBSD if you don't get that experience.

I haven't had a problem with having used pkg on that machine and it's been running since, next in line to update with freebsd-update fetch today.
 
You keep talking about 14.2, which is a release from the future :-/

To "keep it simple", use packages.

---
14 just started as 14-CURRENT and has a LONG way to become 14.0-RELEASE eventually
13 is at -RC3-p1 right now and will become 13.0-RELEASE in a week (hopefully)
12 is at 12.2-RELEASE
11 is at 11.4-RELEASE
Typo! 12.2 is what I have installed!
 
That would be mine.

I used ports in my Tutorial because that was all I'd ever used til recently and the thought of using pkg didn't even occur to me. You can read what I thought were the Pros and Cons and decide for yourself.

It's much faster to use pkg but are you going to know how to fix that vulnerability I found if you've never used ports? It was pretty easy but that's my take on it and I may have overestimated a user to usr in average ability. Natures Way takes care of that sort of thing and those people will rise to the occasion or this is too much for them and it will soon become apparent.

That's why I advise to use one or the other. You may run into problems you don't yet have the experience to solve and succumb to frustration when it could have been avoided. But I am a proponent of Natures Way.

You're a Linux usr so that doesn't apply to you personally, I'm speaking in general terms. Using nothing but ports gave me valuable experience in solving those issues and I think you're missing out on a big part of FreeBSD if you don't get that experience.

I haven't had a problem with having used pkg on that machine and it's been running since, next in line to update with freebsd-update fetch today.
Thanks for the great tutorial! It make installing FreeBSD a pleasant learning experience.
 
You're a Linux usr so that doesn't apply to you personally, I'm speaking in general terms. Using nothing but ports gave me valuable experience in solving those issues and I think you're missing out on a big part of FreeBSD if you don't get that experience.
I do use Linux. BUT I was installing and using FreeBSD back in the early 2000s when Greg 'groggy' Lehey, Ted Mittelstaedt, Giorgos Keramidas and Lowell Gilbert - just to name a few - were resident gurus, fielding my noob questions!!:cool:
 
I got my start with PC-BSD in 2005 and taught myself to use FreeBSD and ports once I got to the desktop. The FreeBSD installer looked beyond my skillset at the time when I had looked at it earlier.

Once I found PC-BSD and got to the desktop I ripped the top off to invoke the Beastie that lie underneath, Soon it was no longer "vanilla" PC-BSD" and I was destined to become Weixiong the Wicked. Black Sheep who bedeviled them for forsaking the flaccid flock that followed them til their dying day.

And I happened to find a screenshot I took running PC-BSD 6.2 or 6.3, just last night.
 
  • Thanks
Reactions: a6h
I got my start with PC-BSD in 2005 and taught myself to use FreeBSD and ports once I got to the desktop. The FreeBSD installer looked beyond my skillset at the time when I had looked at it earlier.

Once I found PC-BSD and got to the desktop I ripped the top off to invoke the Beastie that lie underneath, Soon it was no longer "vanilla" PC-BSD" and I was destined to become Weixiong the Wicked. Black Sheep who bedeviled them for forsaking the flaccid flock that followed them til their dying day.

And I happened to find a screenshot I took running PC-BSD 6.2 or 6.3, just last night.
Our time frames are similar. I should have stuck with one of the BSDs, but other issues got in the way. Starting over!
Still have the old booklet:
 
Many ports create a hidden folder in the users home directory (or under ~/.config, or ~/.cache).
These folders are not created or deleted by pkg. Instead they are checked for and eventually created each time you start the application (port).
Maybe check your home directory with ls -A.
 
Now there's a vulnerability in security/nettle found when building sysutils/gkrellm2.

ports-mgmt/portmaster balked at the idea of installing a vulnerable port on the W520 I'm building FreeBSD 12.2-RELEASE-p4 on. It's one of my have-to-have-it 3rd party programs, too. Sounds serious though:
Code:
nettle-3.6 is vulnerable:
  nettle 3.7.2 -- fix serious ECDSA signature verify bug

I've got one building that can't continue and this one is vulnerable, as are 7 others. What will I do? What will I do... What would you do?

I continued the build and will worry about the rest later when the port is updated:

cd /usr/ports/security/nettle
make DISABLE_VULNERABILITIES=yes install clean
cd /
portmaster sysutils/gkrellm2


Easy to figure out. If you've done it before, can see the full error to know what needs done and know what key allows you to scroll up to see it all. Because you couldn't.

I could easiest by having it start the build over and make Portmaster do what I wanted it to so I could see what needed done to get started again. It's finished building and time to move on with the build.

That's just the way it goes sometime. But that's my take on it, too. And part of the learning process you only get from experience.
 
Back
Top