How to use ports and packages system together?

kupereal

kupereal

Preamble. I installed utility sudo from ports system. Everything is fine! In my version of the OS the package manager (pkg) is already installed. I enter pkg info, and see sudo in the list of applications. It turns out that now I can perform any operations with this software through the package manager. Or is it not recommended and is there a uniform practice on this matter? How to avoid conflicts?
 

Attachments

  • screenshot.png
    screenshot.png
    16.9 KB · Views: 54
so you installed sudo via the repository (pkg install), then you decided to compile the port and install that instead? you can do that. FreeBSD has some smart developers and the port isn't going to be installed alongside the repo package. it is replaced. pkg info will show installed packages and, well, you must have used a make install command.

everything is in order here. no need to worry :)
 
kupereal said:
Or is it not recommended and is there a uniform practice on this matter? How to avoid conflicts?
Click to expand...
The general recommendation is to either use ports or packages, not both. Most people start with packages, then start using ports when config options need to be changed. Which won't be a problem in most cases, just keep track of the exceptions.
The end result of an installed port is an installed package, so you can keep using pkg to keep track of them.
 
As a general rule you shouldn't use both ports and pkg unless there is a compelling reason to do so. You can get yourself entangled in dependency issues.

See the big warning box in the handbook at https://docs.freebsd.org/en/books/handbook/ports/#ports-using

You can take a different approach and use Poudriere or Synth where you compile the binary packages yourself and install those. There are advantages to doing that. Unfortunately, unless you use it to install all of the packages you wish to use you can run into a similar dependency issue (ig if you install only a few packages via local packages and the rest via pkg then you may run into conflicts).

All of this isn't to say you can't do it - there may be reasons to do it. You just need to be aware.

Also note that there are ports that aren't turned into pkgs. One example that I'm aware of is the audio/logitechmediaserver. I'm not sure what the criteria is for those situations. They can be annoying when you run across them.
 
In general, you can sanely mix-up pkgs and anything built locally with ports, if you
  • checkout exact the same commit with the one the latest installed pkgs are built with,
  • using clean room builders like ports-mgmt/poudriere, devel/jenkins,
  • building with default options,
  • and nothing in your /etc/make.conf.
These are because official pkgs are built just like above.

My recommendation for mixing up is that you basically build everything but huge monster leaves (which are NOT depended upon anything else, or depended upon only by their language packs, pure data) like www/chromium and editors/libreoffice. If the pkgs work fine, it is OK as it doesn't affect anything else.

Note that you need to install at least devel/git[-lite|-tiny] from official pkg to pull ports repo (and if you want to build kernel modules ports, src repo, too).

You can install devel/gitup instead if you don't need functionallities of git for developers and / or bisecting problems.

But it (using gitup instead of git) could cause problems you encountered are not fixed for quite a long time even if you reported via Bugzilla or ML, as the maintainers need to bisect problems by themselves only, which could cause them to build, build and build quite a huge mosters repeatedly that are NOT directly affecting the root causes, at worst, strongly depending on the actual problems.

Maintainers/Committers are mostly pure volunteers that can take limited spare times only. So you need to be patient or to be cooperative.
 
Well, we did have a debacle with pkg(8), where valid install/fetch commands returned errors that indicated something is wrong on the other end of the wire, and package was NOT found for some users. I personally prefer ports.

But yeah, don't mix ports and packages unless you have lined up quite a few details, as outlined by T-Aoki above. Version mismatch can bite pretty bad at unexpected times.
 
my 5 cents...
You can use ports alongside with packages, sometimes you must -- for example, it inevitable in case of fresh system release and necessity of use drm-kmod -- kmod from packages will not work with installed kernel, it must be compiled locally.

But the consequences:
* there will be a lot (or a few) packages installed as build-time dependencies by ports system. can be easely removed by 'pkg autoremove'
* next time you run 'pkg update', your packages (that installed from ports) may be queued for updating/reinstalling/removal because of changed options etc. So you should do something to keep it safe, e.g. lock it by 'pkg lock'.

So most inconvinient is last fact. So, by my opinion, if there a few ports installed this way -- you can take an eye on them, e.g. updating in time and so on, at least you'll remember what ports installed by you that way and why 'pkg update' complaining. If not -- if you want more ports with changed options -- read 'man ports' and forum about creating local repository (it's simple), -- just one dir and a few more commands, and install your own packages from local repo. They can be distinguished in pkg outputs by repo name (for packages from Freebsd is FreeBSD, for packages from ports is unknown, from your repo - your repo name), and will not be messed by pkg, and more -- will be updated by pkg if you update them in your local repo from ports.

Next step is poudriere, but I still on that simple local repo.
 
johnjohn said:
so you installed sudo via the repository (pkg install), then you decided to compile the port and install that instead? you can do that. FreeBSD has some smart developers and the port isn't going to be installed alongside the repo package. it is replaced. pkg info will show installed packages and, well, you must have used a make install command.

everything is in order here. no need to worry :)
Click to expand...
Vice versa. I installed sudo (any other software) via make install. Now the package manager sees it, and therefore you can delete and update this software through this manager? Handbook:
The ports system can also be used to generate packages that are then subject to the FreeBSD package management commands.
Click to expand...
 
Things should be fine as long as You use ports from the same repository from where packages are built (don't mix quarterly ports with latest packages and vice versa.)
 
Minbari said:
Things should be fine as long as You use ports from the same repository from where packages are built (don't mix quarterly ports with latest packages and vice versa.)
Click to expand...
If the user hasn't updated the ports tree before installing the utility, the package manager will see an outdated version of the package and update it (overwrite it)?
 
kupereal said:
If the user hasn't updated the ports tree before installing the utility, the package manager will see an outdated version of the package and update it (overwrite it)?
Click to expand...
Yes. Will also happen if the options are different.

Note that it isn't 'overwritten', the old version is removed ( pkg delete -f ....) and the new version is installed.
 
kupereal said:
I installed sudo (any other software) via make install. Now the package manager sees it, and therefore you can delete and update this software through this manager?
Click to expand...
Yes. Building ports a port via 'make install' creates packages edit*: results in an 'installed port'. That is the same end result as installing a package by means of pkg-install(8). Generally packages can be considered the other side of the coin with respect to the ports (framework). I found it confusing when I started FreeBSD, how I interpreted it: two independent systems that are separate: choose one or the other. The latter choice is still valid (for most) but they are not separate or isolated systems or frameworks, there is interaction. Package installations (generally: operations) are administered through the local package database.

It is usually even more confusing for users coming from various Linux distro's. I think it should and could be better explained or emphasized in the man pages or the Handbook.

___
* see astyle's comments below.
 
Last edited:
astyle said:
Erichans said:
Yes. Building ports via 'make install' creates packages;
Click to expand...
It doesn't. You gotta specifically run make package. make install only does the installation part - write the files into appropriate directories, update the local database that keeps track of what's installed...
Click to expand...
With my "Building ports via 'make install' creates packages" I am referring to 4.5.2 Installing Ports:
To compile and install the port, change to the directory of the port to be installed, then type make install at the prompt.
Click to expand...
Also what I see make install results in on my own system:
Code: 
[1-0] # pkg info | grep pkg_tree
[2->1<] # pwd
/usr/ports/ports-mgmt/pkg_tree
[3-0] # make install
===>  License BSD2CLAUSE accepted by the user
===>   pkg_tree-1.1_6 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by pkg_tree-1.1_6 for building
===>  Extracting for pkg_tree-1.1_6
=> SHA256 Checksum OK for pkg_tree-1.1.tar.gz.
===>  Patching for pkg_tree-1.1_6
===>  Applying FreeBSD patches for pkg_tree-1.1_6 from /usr/ports/ports-mgmt/pkg_tree/files
===>   pkg_tree-1.1_6 depends on package: perl5>=5.36<5.37 - found
===>  Configuring for pkg_tree-1.1_6
===>  Building for pkg_tree-1.1_6
--- pkg_tree.7 ---
pod2man --section=7  --release="December 15, 2001"  --center="FreeBSD System Manager's Manual"  --date="December 15, 2001" pkg_tree.pod > pkg_tree.7
===>  Staging for pkg_tree-1.1_6
===>   pkg_tree-1.1_6 depends on package: perl5>=5.36<5.37 - found
===>   Generating temporary packing list
install  -m 555 pkg_tree /usr/ports/ports-mgmt/pkg_tree/work/stage/usr/local/bin
install  -m 444 pkg_tree.7 /usr/ports/ports-mgmt/pkg_tree/work/stage/usr/local/share/man/man7
====> Compressing man pages (compress-man)
===>  Installing for pkg_tree-1.1_6
===>  Checking if pkg_tree is already installed
===>   Registering installation for pkg_tree-1.1_6
Installing pkg_tree-1.1_6...
[4-0] # pkg info | grep pkg_tree
pkg_tree-1.1_6                 Get a 'graphical' tree-overview of installed packages
[5-0] #

I don't view that as a confirmation of your statement "It doesn't." ( but maybe I'm wrong ... )
 
Erichans said:
# pkg info | grep pkg_tree pkg_tree-1.1_6 Get a 'graphical' tree-overview of installed packages
Click to expand...
This only confirms installation, not actual creation. Pay attention to what the install command does:
Erichans said:
install -m 555 pkg_tree /usr/ports/ports-mgmt/pkg_tree/work/stage/usr/local/bin
Click to expand...
Actually creating a package takes the make package command, and you'll end up with /usr/ports/category/my_package/work/pkg/my_package.pkg. Without that, you don't have a created package. pkg-info(8) only reads contents of the database that keeps track of installed stuff.
 
Erichans said:
It is usually even more confusing for users coming from various Linux distro's. I think it should and could be better explained or emphasized in the man pages or the Handbook.
Click to expand...
A port allows you to adapt an application somewhat to your needs, there is not much more to it. Once you know that, man ports will get you going.
Coming from Linux, I started with pkg too, since its basically the same as rpm, yum and the others in Linux.

What got me to start building ports where audio applications. Installing packages of audio apps will also install the audio back ends that these apps can work with. So I soon had alsa, pulseaudio, jacks and sndio installed and running. And I had all sorts of audio problems because of that. I solved that by using ports. Config options usually allow you to choose a back end, OSS only in my case. Now all audio apps work fine with OSS only. Additionally I use audio/virtual_oss to address inputs and outputs of an external DAC/ADC, so I don´t have to use the Windows driver for it.

For several years I build ports for all audio stuff and installed packages for the rest. Hardly ever had real problems that way. Later on I turned it around, I build everything from ports now. Except for rust, llvm and gcc. If one of these needs updating I will install the package if it's available, just to save time. I used portmaster and later portupgrade to keep ports updated. Will try synth if I have time.

The general rule (either ports or packages) is certainly valid, but it doesn´t necessarily mean you will run into problems if you start using both. Just know what you are doing by keeping track of which ports and which packages. And once you start using ports, make sure you always 1) update your ports tree, 2) have a clean building environment (no leftover work-directories) and 3) follow the instructions in /usr/ports/UPDATING first. You will find ports a great addition to packages.
 
Erichans said:
I don't view that as a confirmation of your statement "It doesn't." ( but maybe I'm wrong ... )
Click to expand...
Here's another noodle for you: the full command you should actually be using is # make install clean, because why on earth would you want to leave all that temporary mess behind?

Yet this also implies that if you just use the install build target then everything that got created in the process is still there in the work staging folder. So... go look for a package I'd say ;)

I'm serious by the way, because that's exactly what I did after I discovered that one of Portmasters touted features was to keep backup packages of upgraded ports. At first I assumed that this was just Portmaster flaunting with features that the ports collection already provided out of the box... all they had to do was to copy the package that was already being build, right? Well, no, things didn't work that way at all.

When in doubt... why not go look yourself?
 
kupereal said:
Or is it not recommended and is there a uniform practice on this matter? How to avoid conflicts?
Click to expand...
Others have already explained that this is generally speaking a bad idea. The unwritten rule is basically not to combine ports and packages, period. But ... there is a gray area.

This is actually another good example of why I became such a huge fan of ports-mgmt/portmaster because it does something kinda unique: it divides ports into very specific categories:
  • Root ports => Ports that don't depend on other ports and are not being required by others either.
  • Trunk ports => Ports that have no dependencies themselves, but are being required by others.
  • Branch ports => Ports that have dependencies of their own, and are being required by others as well.
  • Leaf ports => Ports that have dependencies of their own, yet are not being required by others.
If you don't fully understand what I mean then just install Portmaster, then run portmaster -l and you'll see what I mean. Also... this is obviously about run dependencies, not build stuff.

Well, I think this should speak for itself... You see, the real culprit when mixing ports & packages is the dependence system. If you change options during building then this can cause issues when a binary package has a certain requirement. Yet if that binary package happens to be part of the 'root' or 'leaf' category then you wouldn't have to worry about that perse.

I basically only rely on binary / premade packages on workstations (because then I can't be bothered with the build time), and also on backup servers (because then I build stuff on a main server, set up my own repo and feed that into my backups).
 
You must log in or register to reply here.
Back
Top