10

We have development environment on FreeBSD 10.3. I've heard that FreeBSD manages package dependencies in that way, that it always looks for the newest version of all packages, which main package depends on. And it looks like true. So, my questions are:

  1. Is this true? is there any official documents that prove it?
  2. The best way how to overcome this problem?
  • 7
    I suspect, you can install the package of the specific version you require first, then pkg lock it, and then install everything else you want. – arrowd Feb 21 '17 at 9:19
  • 1
    It also depends on what port/package you want and in which version. For example you can have different python/postgresql/php versions. Sometimes there are multiple packages available for a software, sometimes you can build your special package from ports. – Raphael Ahrens Feb 21 '17 at 15:28
  • 3
    If you blindly run freebsd updates (or pkg upugrade), yes, it will find the newest it can and try to install that. As arrowd said, now (since 9.2 or so), you can pkg lock <pkg> which should protect what you have installed and its dependencies from modification. YMMV. – quadruplebucky Jun 12 '17 at 2:54
1

How FreeBSD Builds Packages

The FreeBSD project used to build packages only for releases and occasionally for the STABLE branches. The old package builders used a distributed system named Portbuild. It would use a large cluster of smaller 2GB-4GB machines to build packages. This was error-prone and slow, mostly due to the older machines. A full build could still take a week. Today packages are built using single large machines using Poudriere. (From webpage by Brian Drewery).

See also: How to update a mix of packages and ports on FreeBSD

FreeBSD has an evolving ABI (and API) as does Solaris and Windows while Linux has a stable (stagnant?) ABI (and API) so with Linux old binaries will still run on a newer OS version while with non-Linux OSes this isn't always the case (sometimes it is).

Using pkg lock can still lead to headaches, while it will lock (offer a warning) when you try to upgrade using pkg upgrade it still presumes that higher numbered versions are better (desirable) and that it is something you would want to do - so it asks permission, and you can allow, but it doesn't guarantee something else won't be broken. See above URL, or this discussion: "Would you prefer FreeBSD to lock versions of binary packages distributed via pkg for an OS version?".

If one package is locked sometimes you will have to give permission to unlock it and do the upgrade, while that will work for the one package (and all its dependencies) there's no assurance that something else won't be incompatible with the new libraries (and thus also need an upgrade, if one is currently available).

Brian Drewery's Blog: "FreeBSD Journal: Poudriere" opines:

"Stop using portmaster, portupgrade and ports on your servers and switch to packages.

Setting up your own package builds with Poudriere takes only a few minutes and will save you a lot of time in the future.

...

If you are maintaining more than one FreeBSD system and are not using packages already, you should. I maintain only 20 servers, but building ports on each system took a lot of my time and wasted resources on production machines. When building ports on multiple servers, it is very easy to get their options or versions out of sync. By building packages once on one system, I lessened the load on my systems, lessened the amount of work I had to do and made all my systems consistent. Instead of dealing with the same failure on each system, I only need to handle it on the build system.

But, the hitch ...

Why would you need to deviate from the official packages? The ports framework provides options support for ports to change build-time configuration. Not all applications support run-time configuration. Some applications must be compiled differently depending on which features are enabled. Others have options simply to lessen the amount of features and dependencies in the default port. For server administrators, this can quickly lead to finding that some of the default packages do not meet their requirements.

So ...

There are a few ways to get custom packages. Pkg supports using multiple repositories. It can be set up to use the official FreeBSD repository as a primary and a custom one as a secondary. Pkg is not limited by the number of repositories it can track and they can be reordered for priority. The problem with multiple repositories is that it can currently be difficult to maintain. When Pkg detects that an installed package has different options or dependencies from a repository it is tracking, the package will be reinstalled from potentially any remote version. You can either lock the package during upgrades with pkg lock PKGNAME and pkg unlock PKGNAME or bind it to a specific repository with pkg annotate -A PKGNAME repository REPONAME. There is also the subtle problem of keeping the ports tree for your custom repository in sync with the FreeBSD packages. Since packages are built from a ports tree snapshot taken once a week, if your custom repository does not match it may lead to conflicts. It is much simpler to just build an entire package set of just what you need with the options that you want.

The solution:

Poudriere (roughly pronounced poo-dree-year, French for “powder keg”) was written as a faster and simpler replacement for Tinderbox. It was written by the Pkg author Baptiste Daroussin and is now mostly maintained by me along with Baptiste and some other contributors. It has quickly become the de-facto FreeBSD port testing and package building tool. It is the official build cluster tool and is also used by the FreeBSD Ports project for testing sweeping patches in what are called “exp-runs”. It is written in POSIX shell and is slowly being moved to C components. Unlike Tinderbox, it has no dependencies and does not require a database. It has been greatly optimized to be highly parallel in all operations. It uses jails to build ports in sandboxed environments in very strict conditions. Jail creation is done once with a simple command. During builds, the jail is cloned automatically for each CPU being used to give ports a clean place to build.".

Setting up your own repository with poudriere lets you have the flexibility of ports and the ease of management of packages.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.