# pkg vs ports + advice maintaining a system ?



## zeugme (Feb 15, 2019)

Hi community !

I'm trying to switch to FreeBSD, and wondering few basic questions on differences between pkg and ports:

it is possible not to use ports at all but rely only on pkg ? Any limitation ?
what would be the benefit of using ports outside compile parameter and maybe hope for better fit to hardware ?
Maintaining a system up and running: if I understood correctly, update packages is done with pkg while updating the system is done with freebsd-update.
With this separation, one difference with Debian, what advice would you give me to ensure it all works fine :

newer packages on older system : will that work ?
newer system on older packages, less likely to occurs, but what is the risk ?
I understood security updates can come from both freebsd-update, when security issue was in the system, and from pkg when security issue was in a package.
Am I correct ?

Then, how can I distinguish (and is it useful to distinguish ?) security patch from version upgrade for package and system ?
I got the feeling, both security patches and version upgrades will come together with a pkg update. Is this true ?
If true, could this be a problem ?

Any advise or pointers to read are welcome !

Note: I'm asking within several use cases in mind: servers, desktop, laptop.

Thanks.


----------



## SirDice (Feb 15, 2019)

zeugme said:


> it is possible not to use ports at all but rely only on pkg ? Any limitation ?


Yes, it's actually the recommended way. Limitations? Yeah, dependencies are set in stone. 



zeugme said:


> what would be the benefit of using ports outside compile parameter and maybe hope for better fit to hardware ?


There's only one reason to use ports, when you want to deviate from the default options. Ports already use the most optimal settings so there's very little to gain from a strictly performance viewpoint. 



zeugme said:


> I understood security updates can come from both freebsd-update, when security issue was in the system, and from pkg when security issue was in a package.
> Am I correct ?


Correct.



zeugme said:


> Any advise or pointers to read are welcome !


Yes, if you have multiple machines to maintain, set up your own repository. That allows you much greater control over updates (when/where/what), you can change defaults (use MariaDB instead of MySQL for example), you can turn options on/off. And if all your machines use the same repository you can be sure everything is the set up the same too (standardization). 



zeugme said:


> Note: I'm asking within several use cases in mind: servers, desktop, laptop.


I've set up two "sets" of repositories, one specific for servers (no X11 stuff) and one specifically for desktops (X11 all the way). This was much easier to do than trying to find a single, common, configuration that worked everywhere.


----------



## zeugme (Feb 15, 2019)

SirDice said:


> Yes, it's actually the recommended way. Limitations? Yeah, dependencies are set in stone.


A good limitation to me, so we know it should work as a black box.

OK, so pkg only !


----------



## msplsh (Feb 15, 2019)

zeugme said:


> it is possible not to use ports at all but rely only on pkg ? Any limitation ?
> what would be the benefit of using ports outside compile parameter and maybe hope for better fit to hardware ?



The benefit is enabling features in programs such as SQLite or PostgreSQL support, which is disabled by default in some packages like APR, which will in turn not allow certain database backings in Apache.


----------



## SirDice (Feb 15, 2019)

That's when custom repositories are extremely useful. It gives you the best of both worlds. You get the flexibility of ports and the ease of management from packages.


----------



## ShelLuser (Feb 15, 2019)

And also important: keep in mind that it's best to use either ports _or_ packages ('pkg') but don't use both at the same time. If you mix the two together then bad things(tm) can happen to your system.


----------



## Wozzeck.Live (Feb 15, 2019)

Theoretically.... most people coming to FreeBSD at a moment will choose ports, because you come to FreeBSD to be free to "cook" your system in as many way you want.

And don't expect to combine ports and standard packages....this point is regularly discussed in this forum. From the moment you choose custom options from ports, you affect the chain of dependencies, so at a moment you will break the standard package system. In fact, on package update the system will attempt to rollback any customized port to standard packages.

But....  it will also depend on your hardware.

If you run old hardware, maintaining a port system can be painful.

Le'ts take an absurd and stupid example....
You run a Raspberry and you want to compile chromium.... it could take, let's say 7 days, as chromium is well known here to be probably the longest port to compile.

That's also for saying... it depends on what you want to compile.
If you intend to install a light headless server, so with no desktop, with some hardware more powerful than a Raspberry... yes, you can choose ports and "cook" your system.

Other scenario... your hardware is light, very light.... but you absolutely need some custom options for some ports.
The solution is to use "poudriere" on another FreeBSD server running with a good processor which will compile the ports and build custom packages in a http, ftp, repository.

Your light server will install ports through you precompiled custom packages... Custom packages have exactly the same format as the standard packages... they just differ in the options, and so that modifies the chain of dependencies.

Addendum :
------------
Please note that ports-mgmt/portupgrade tool can intelligently combine ports and standard packages if possible.
The following command `portupgrade -aRP` means :


a : update all installed port
R : before updating a given port, update dependencies before if required. What we call backward dependencies.
P : use package if possible
So portupgrade  will download and install standard package for a given port, rather than building it, if :

the given port "A" is set to its default options
all dependencies (so running dependencies and building dependencies) of port "A" are set to their default options
In any other cases, portupgrade tool will build the port "A"

In fact, if you install a little system with only a few ports with custom options, generally you can combine packages and ports through the "portupgrade" tool
If you install a bigger system, as a desktop, this implies a bigger number of ports and so this is creating a very complex chain of dependencies. So there are only few chances for "portupgrade" to install standard packages.
It also depends on the level of dependencies. If you customize essentials packages as Perl, Python.... automatically it affects number of forward packages.
If you just customize an end user application as "firefox", there is generally no impact on the chain of dependencies as Firefox is rarely a backward dependency.

Anyway, when I choose "port", I personally don't try to combine package, so I never use the "P" option with "portupgrade", because any failure in building a port "A" may reveal related backward dependencies issues.
So first you generally rebuild the dependencies... and you rebuild port "A"
If "portupgrade" installs package "A", it will not warn you on such issues and so you may find the program not working... with no explanation

In a canonical way, if you want to secure a process, if you update "port A", you should also force rebuild all ports that have "port A" as dependency, what we call "forward" dependencies, corresponding to "r" option in "portupgrade" tool.
But this is only theoretical, because updating a very low level package as python, perl ... should theoretically result in a full system rebuild.
For the common user, this is simply not possible as his computer would be used  90% of its time to build, build and always build packages.
This is possible for little systems with few packages, or for some professionals who have powerful "poudriere" dedicated machines, focused on building custom packages, and so able to rebuild all installed port, and serve them in a repository in just a few hours per day.

For any standard user... he takes the risk to not rebuild the forward dependencies, and so do that on "request" when a problem occurs

If you install a big desktop as Gnome, KDE5.... rebuilding a full system can take several days speaking of standard desktop machines, this is the reason why "theory" is not applicable for most of us.


----------



## gpw928 (Feb 16, 2019)

zeugme said:


> A good limitation to me, so we know it should work as a black box.
> 
> OK, so pkg only !


Hi,

If only it were that simple.  As intimated above, you may need to deviate.  e.g. sendmail, as packaged on FreeBSD 11.2, won't talk to Google SMTP servers.  I use them, so I must custom configure the sendmail port.

Other things come to mind, like CUPS which invaded the traditional lpr/lpd name space.  Some really important things like web browser packages have CUPS as a dependency, so it gets dragged in when you install a browser package, but not configured.  Then lpr suddenly stops working (because the CUPS one is first in my PATH).  Initially, I used ports for anything that had CUPS as a dependency so as not to break lpr/lpd.  But I finally got beaten into submission.  I just recently dumped lpr/lpd (which had worked brilliantly for decades) and went with CUPS across the board -- just so I could use packages.

I did this because using ports for major applications means it will take an eternity to build a new system.  I have another life, and value it...

My point is that the "recommended way" (packages only) is not really practical in a wide number of circumstances.


----------



## zeugme (Feb 16, 2019)

OK, thanks to you, I got the point for the differences between ports and pkg.
I'll go the pkg way. No time neither wish to configure that deeply software for my general use case.
Maybe using port on a server when no other solution just for 1 or 2 software ...

Still one question on maintaining a healthy system + software :


> how can I distinguish (and is it useful to distinguish ?) security patch from version upgrade for package and system ?
> I got the feeling, both security patches and version upgrades will come together with a pkg update. Is this true ?
> If true, could this be a problem ?



And also, how do I correctly use freebsd-update and pkg update together so nothing break ?
Can it break ?
Currently, I feel confident in the Debian way to solve this with security patches only update.
There are other limitations on Debian as a consequence, but how does it works on FreeBSD to ensure healthy system ?

Any good practices for this 2 actions : freebsd-update & pkg update ? (appart from a snapshot)


----------



## Deleted member 30996 (Feb 16, 2019)

Wozzeck.Live said:


> Theoretically.... most people coming to FreeBSD at a moment will choose ports, because you come to FreeBSD to be free to "cook" your system in as many way you want.



I use ports instead of pkg in my Beginners Tutorial, the only person to do so I'm aware of ATM and can't count how many times I've caught heat for it. Using pkg never even occurred to me when I wrote it. 

But I'm OK with that and always open to constructive criticism. It's how I learned and I enjoy using ports. Probably because I struggled with it since I didn't read the Handbook back then. I didn't think it applied and nobody said anything, as usual.

And it makes my OCD all warm and fuzzy.


----------



## micski (Mar 2, 2021)

I have experienced, that more and more packages break the system, when trying to update. Examples are Intel graphics and similar dependencies, used on desktop computers. I was then forced to fall back to a mix og packaages and ports, if not dealing with a bricked system. Is this trend a time to switch to ports?


----------



## msplsh (Mar 2, 2021)

Might have something to do with this sort of tension between 11 and 12:









						Solved - Certbot stopped working due to cryptography>=3.2
					

Hello,  Certbot doesn't work due to cryptography >= 3.2   pkg_resources.ContextualVersionConflict: (cryptography 2.9.2 (/usr/local/lib/python3.7/site-packages), Requirement.parse('cryptography>=3.2'), {'PyOpenSSL'})   Need advise on how to continue, abondon certbot for acme.sh or wait? Can you...




					forums.freebsd.org
				




Are you still on 11?


----------



## SirDice (Mar 2, 2021)

micski said:


> Examples are Intel graphics and similar dependencies


It broke because during the transition period (when both 12.1 and 12.2 are supported) packages are built for the lowest version. Unfortunately this caused problems for these specific packages on the newer version. For all other packages (99% of the 40.000+) this wasn't a problem but the graphics/drm-kmod packages were the notable exception to this rule. As 12.1 is now officially EoL packages are built for 12.2 specifically and this issue resolved itself. 



micski said:


> Is this trend a time to switch to ports?


It's not a trend, it was a temporary issue.


----------



## jardows (Mar 2, 2021)

micski said:


> I have experienced, that more and more packages break the system, when trying to update. Examples are Intel graphics and similar dependencies, used on desktop computers. I was then forced to fall back to a mix og packaages and ports, if not dealing with a bricked system. Is this trend a time to switch to ports?


Unlike some, I don't have problems mixing a few ports with packages.  Since I'm using just a couple of machines, I install from packages everything unless I specifically need to change the options (such as with /emulators/virtualbox-ose).  What I install from ports I lock.  I run Latest repository for packages, but only do a system-wide update about once a month.  Then I unlock the package and upgrade it from ports.  Since I only have about three programs I need to install from ports (drivers with minor version change and virtualbox customizations) this is manageable.  Some day I may want to work with more extensive customizations, but that is not today.


----------

