A mini-FAQ on pkg

Status
Not open for further replies.
Please post that info here. Most of the time I cannot connect to wonkity.com :mad:

Now you posted it here, please "stickify" it .... and you can delete this post
 
A temporary version until we figure out the connection problem:
  1. What is pkg or pkgng?

    The new package management system on FreeBSD. pkg is the preferred name now.

  2. Should I use pkg?

    Yes. In fact, if you want to keep using binary packages or ports built after September 2014, it is required.

  3. How can I tell which package management system is installed?

    FreeBSD 10.1 and later do not include the old package management system. On earlier systems, running pkg info shows a list of packages if pkg has been installed, or offers to install the new package management system if it is not present.

  4. If I switch, can ports still be used?

    Of course. When a port is compiled, it actually creates a package. The package is then installed and managed by the package management system. A binary package is the same, it has just been compiled on a different computer.

  5. How can I switch to pkg?
    • portmaster ports-mgmt/pkg to install the port.

    • pkg2ng to read the old package database and write the new one. Do that conversion only once.
  6. After switching to pkg, can the old pkg_* commands still be used?

    No, do not use the old pkg_* commands any more. The database they use is likely to be outdated or not even present. The new pkg commands are similar, but the pkg command is followed by a space and a subcommand, like pkg info.

  7. Can the old package database files be removed?

    The pkg database is a SQLite file called local.sqlite in /var/db/pkg/. The old package database consisted of a subdirectory for each package in this same directory. All of those old subdirectories can be deleted, although portmaster uses them to keep track of things and will recreate them.

  8. What is Poudriere?

    An automated system that builds binary packages out of ports. This is what the FreeBSD cluster systems use to build binary packages. It can also be used by individuals to build their own customized binary packages. If several machines need the same applications, one system can be used to build those binary packages from ports, and then all of them can quickly install the resulting binary packages.

  9. Is Poudriere required to build from ports?

    No. The standard make build/install/clean ports commands work fine. Poudriere just makes it possible to build binary packages from ports in bulk.

  10. Should I use ports or binary packages?

    It depends. Binary packages are convenient because they require no compiling. However, they do not allow customized options. For an example, consider the many options of the www/nginx port. In a binary package, these are set to defaults and cannot be changed. Ports must be compiled, but can be customized and optimized for an individual system or use. If you support multiple machines, Poudriere makes it possible to build customized binary packages for them, requiring no build time on the target system.

  11. When will FreeBSD drop ports altogether?

    Binary packages are created from ports. So the answer to this question is "probably never". However, a computer that uses only binary packages does not need a copy of the ports tree.
 
This is a temporary post, at least unless we find out there is an ongoing problem with access to my site.
 
wblock@ said:

If I switch, can ports still be used?

Of course. When a port is compiled, it actually creates a package. The package is then installed and managed by the package management system. A binary package is the same, it has just been compiled on a different computer.
Click to expand...

Hi there,
I've got a question in regard to the above point (was No. 4 in the original complete list). Thank you for this collection, wblock!

On my 10.2 machine I've got a lot of binary packages installed as well as a few from the ports tree. The latter ones have some special compile settings, which I needed and which I want to keep installed. When a new release turns up, let's say openssl, I at first see this by running 'pkg update && pkg upgrade', which I do regularily as everyone here probably does.
Now, when I'm not as alert as I should be in such situations, I type yes and the freshly downloaded standard binary openssl gets installed -- right over my former custom build. This is no drama when I notice this mishap instantaniously, but every now and then it slips through my fingers and later I find myself wondering why applications do funny things. Or worse.

So, my question is: how can I convince pkg of not touching my custom builds when newer releases show up? I'd like to be notified, though, so that I can head over to ports tree and do the update business there in combination with my special settings.

Thank you for any hints or forwarding pointers.
 
Packages can be locked, but beware that this can cause surprises when a package really does need to be updated. One solution is to build all your own custom packages. Or build everything from ports, today's hardware makes it more practical than ever.
 
Very useful for a beginner like me ! thanks !

One question that will certainly sound very stupid to you all.
Why is it necessary to compile to have options available? Wouldn't it be more simple to have all options included and activate them with a conf file?
 
Last edited by a moderator:
Some options require additional code and/or dependencies and not everything is tunable with configuration files.
 
So if I understand correctly.
- It's to save disk space
- It's also because of the conception of certain software that does not let the user to have access to all settings through a conf file.

Am I right?
 
Last edited by a moderator:
More or less. There are also conflicting options (where only one can be enabled) and a whole bunch more.
 
Hi All,

For a given package, how can I determine what will be installed before I install the package?
After I install a package, how can I determine what has been installed?

I did not see a specific package command for this. However, I might have missed it.


=thoth=
 
ThothK said:
However, I might have missed it.
Click to expand...
When you install a package this is presented to you to confirm installation:
Code: 
root # pkg install stress
Updating local repository catalogue...
Fetching meta.txz: 100%    260 B   0.3kB/s    00:01    
Fetching packagesite.txz: 100%  139 KiB 142.5kB/s    00:01    
Processing entries: 100%
local repository update completed. 596 packages processed.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	stress: 1.0.4

Number of packages to be installed: 1

22 KiB to be downloaded.

[b]Proceed with this action? [y/N]:[/b] y
Fetching stress-1.0.4.txz: 100%   22 KiB  22.6kB/s    00:01    
Checking integrity... done (0 conflicting)
[1/1] Installing stress-1.0.4...
[1/1] Extracting stress-1.0.4: 100%

So you see before installation what is going to be installed (with dependencies, but there aren't any in this example). Here you can deny installation or confirm. And it is then shown what actually has been installed.
 
Hi GetOpt,

I have seen that. That tells me what packages are going to be installed or upgraded.

I want to know the actual files that are copied to the filesystem, what configuration changes are made, etc.


=thoth=
 
You can list the package dependencies of the newly installed package with pkg info -d blah.1.0 and you can list the files in those dependencies pkg info -l blah.1.0. There's probably a more concise way to do it, but to give you what you want in one command, how about something like pkg info -d blah.1.0 | cut -d':' -f1 | xargs pkg info -l?
 
ThothK said:
I want to know the actual files that are copied to the filesystem
Click to expand...
Packages just contain files to be copied to the system. So the information of your desire are in the package where it can be retrieved:
Code: 
# tar tf /var/cache/pkg/stress-1.0.4-2a6787cc16.txz 
+COMPACT_MANIFEST
+MANIFEST
/usr/local/bin/stress
/usr/local/man/man1/stress.1.gz
/usr/local/share/licenses/stress-1.0.4/catalog.mk
/usr/local/share/licenses/stress-1.0.4/LICENSE
/usr/local/share/licenses/stress-1.0.4/GPLv3
/usr/local/info/stress.info

There it is! Just disregard the files with '+'.
 
Thanks for this!

I'm looking for a way to upgrade all my packages using pkg from now on. I was looking at
Code: 
pkg upgrade
.

When I do that I get:
Code: 
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (2 candidates): 100%
Processing candidates (2 candidates): 100%
Checking integrity... done (0 conflicting)

Why isn't it in fact updating those 2 candidates? Should I force it? if that's the case, how do I do that?

I have looked at pkg_upgrade from bsdadminscripts-6.1.1_8, but that just gives an error message and exits.
 
This thread has cleared up a LOT of things for me. It actually spawned some questions that have always bugged me.
1. Then I assume Ports and Packages use the same database to keep track of what is installed?
2. I'm guessing this is a database for the ports tree to resolve dependencies? I run portsdb -u and on new installs portsdb -U. I also see in the manual portsdb -F and says it is faster than -U, so I guess on a new ports install that I would be better off doing thee -F.
3. SOP is to run pkgdb -F to fix duplicated origins. When it happens I end up having to read docs that come with the ports tree version. What exactly are duplicated origins, and why are they not resolved before ports trees are released?
4. There are portupgrade –rR and pkg_info –rR. Since you wouldn't necessarily need to have ports installed, are these two commands pulling their information from two different sources to determine dependencies?
5. I see references to repository. What, where is it, and what does it do?

Thanks TONS!
 
1. Yes, there is only one database, everything is a package by the time it gets installed on your system.
2. portsdb is part of portupgrade (or was). I thought it didn't use that any more. It is not a native part of the package system.
3. Duplicated origins means you are doing something wrong in the first place.
4. No idea what -rR does with portupgrade. Do not use pkg_info at all any more, it is obsolete.
5. A repository is an online place to keep things that can be downloaded. Source code, binary packages, whatever.
 
wblock@ said:
No idea what -rR does with portupgrade
Click to expand...
That tells port upgrade to check and update dependencies and depends on.

Which tools are the best in your opinion for maintaining ports with FreeBSD 11?

PS: I assume for servers without GUI, that this should still be added to make.conf:
WITHOUT_X11=yes
WITHOUT_X=yes
WITH_X=NO
ENABLE_GUI=NO

Thanks TONS!
 
IT_Architect said:
That tells port upgrade to check and update dependencies and depends on.
Click to expand...
Ah, I remember the old "pirate" option: -arR.

IT_Architect said:
Which tools are the best in your opinion for maintaining ports with FreeBSD 11?
Click to expand...
That is currently a loaded question. I use ports-mgmt/portmaster, which, according to some, is the most evil thing possible. Yet it still works. Other people use binary packages from the FreeBSD package repository with pkg, and that can be adequate. Still others set up their own package builders locally, essentially doing the same thing the FreeBSD package repository does, but allowing them to have their own binary packages with customized options.
 
Status
Not open for further replies.
Back
Top