# What is better to use? pkg or portmaster



## razsnic (Dec 10, 2017)

Are _pkg_ and _portmaster_ equivalent? Is it better to use _pkg_ or _portmaster_? To me they should be equivalent, and both should maintain the same version of software installed on the system, however I noticed inconsistencies.

I have been playing around with a test system (FreeBSD 11) and I've noticed that some software that was installed with _pkg_ is marked to be upgraded by _portmaster_, and some software installed by _portmaster_ is marked to be upgraded by _pkg_, even though they are the same version.

For example:

php71 was installed by _pkg_ as version php71-7.1.12.

If I run _portmaster-L,_ I see that it wants to upgrade php71-7.1.12 to php71-7.1.12_1

===>>> php71-7.1.12
        ===>>> New version available: php71-7.1.12_1

_pkg upgrade_ does not show any new version of php71-7.1.12

$ _sudo pkg upgrade_
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (22 candidates): 100%
Processing candidates (22 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.

Why this strange behavior? Is there a way to fix this?

Thank you.


----------



## MarcoB (Dec 10, 2017)

Pkg is for installing precompiled ports (with default options set). Portmaster is for building and installing from sources.


----------



## getopt (Dec 10, 2017)

FreeBSD has a great Handbook. See https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html 



razsnic said:


> Why this strange behavior? Is there a way to fix this?


There is nothing strange and nothing to fix. The ports tree always is ahead of any repositories just because the binaries have to be build before you can fetch them.


----------



## razsnic (Dec 10, 2017)

getopt said:


> FreeBSD has a great Handbook. See https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html
> 
> 
> There is nothing strange and nothing to fix. The ports tree always is ahead of any repositories just because the binaries have to be build before you can fetch them.



I did read the handbook chapter on installing applications using the ports and packages, however it didn't answer my question. If you install for example, php71-7.1.12 using _pkg_, then why _portmaster_ wants to upgrade it to a "new version" (php71-7.1.12_1), when in fact it is the same version? Shouldn't portmaster say there's nothing to upgrade? Right now I am confused whether to use only the port collection or just the package collection. I believe that using both at the same time, will create problems. Do you use both collections, do you install some apps using binaries (packages) and other apps using the port collection?

Thanks.


----------



## razsnic (Dec 10, 2017)

MarcoB said:


> Pkg is for installing precompiled ports (with default options set). Portmaster is for building and installing from sources.



Hi Marco.

I am aware of their purpose, but shouldn't both methods (packages and ports) keep track of the same version of an application? Is php71-7.1.12 (installed by _pkg_) different from php71-7.1.12_1 (installed by _portmaster_)?


----------



## MarcoB (Dec 10, 2017)

They're both the same version (7.1.12) but the port got updated because another port (dependency of php) probably got updated (hence the "_1"), and the php-port actually needs to be rebuilt because of this. The ports tree changes constantly, the packages do not. By default, packages only get updated every three months.


----------



## Minbari (Dec 10, 2017)

First golden rule on FreeBSD don't mix ports with packages unless you know what are your doing and second: software it's always updated first in ports by ports maintainers and after that with tools like portmaster/podrier/synth are created packages. If you want to have newer packages you can use the "latest" branch of packages instead of quarterly (/usr/local/etc/pkg/repos/FreeBSD.conf)

```
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
```


----------



## getopt (Dec 10, 2017)

MarcoB said:


> ... but the port got updated because another port (dependency of php) *probably got updated* (hence the "_1"),


"Probably" ... but ...

We have explicit and clearly defined terms and rules on naming versions.
You can learn there about DISTVERSION and PORTVERSION: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-naming.html

5.2.3.1. there explains when PORTREVISION must be bumped.

Furthermore you can look up such things exactly without any need for speculations:
https://svnweb.freebsd.org/ports/head/lang/php71/Makefile?r1=455566&r2=455565&pathrev=455566


----------



## ShelLuser (Dec 11, 2017)

Seems no one actually explained anything yet 



razsnic said:


> Are _pkg_ and _portmaster_ equivalent? Is it better to use _pkg_ or _portmaster_? To me they should be equivalent, and both should maintain the same version of software installed on the system, however I noticed inconsistencies.


Both are two totally different things.

pkg is FreeBSD's package manager and installer. You can install/query and remove packages from the system (that's the management part) but you can also grab software from a remote repository which is handled by the installer part. A package is basically nothing more but a compiled piece of software, usually originating from the ports collection but that doesn't have to be the case.

Another important thing to realize is that PKG is also used to install ports. If you install a port (so: using the classic `# make install clean` method in a port directory) then this will basically do nothing more but create a package, which then gets installed by PKG. This is also the reason why all ports in the ports collection depend on at least 1 port: ports-mgmt/pkg. Simply because they need this to be present, otherwise a port can't get installed.

And speaking of ports... that's where Portmaster comes into the picture. Portmaster is a script which can make it easier on you to install ports. Some specific advantages are making sure that you'll see all config options for all involved ports shortly after each other. In a vanilla process (so; using the make command I mentioned earlier) this is done on a per-package basis. In other words: if I start building Apache then it's perfectly possible that I'll get a new port config screen somewhere half way, after 20 min or such. And after I configured that port the other one can show up 30min after that. Or 5...

One way to overcome that is to use `# make config-recursive`, but Portmaster can also handle this for you.

So Portmaster is simply a tool which can make it easier to install and somewhat manage ports.

Portmaster builds and installs ports, for which it uses PKG.

As such: you can't compare these two in the way you did. One isn't "better" than the other because both do totally different things. And as mentioned: Portmaster wouldn't even be able to run withing PKG being present.



razsnic said:


> php71 was installed by _pkg_ as version php71-7.1.12.
> 
> If I run _portmaster-L,_ I see that it wants to upgrade php71-7.1.12 to php71-7.1.12_1
> 
> ...


First of all: this is a very bad idea. Do not mix ports and packages, if you want to know why then my guide about ports and packages might interest you.

But this is also very easily explained. By default PKG uses the so called quarterly repository, see /etc/pkg/FreeBSD.conf. And that repository follows the ports collection, but at later intervals. There's also the 'latest' repository but even with that you'll see this same behavior.

See, the thing you need to keep in mind is that those binary packages is nothing more but pre-compiled software from the ports collection. As such the ports collection itself will always be ahead of the binary repositories. First a new (or updated) port comes out, then the repositories will compile and test that and only after that process will the software be made available in the repositories.

SO.. there's no fix required, this is all working as intended.


----------

