0

A FreeBSD package typically specifies dependencies in its manifest as follows:

deps:
  # python39, version 3.9 or higher
  python39: {origin: lang/python39, version: 3.9}
  # bind-tools, any version
  bind-tools: {origin: dns/bind-tools}

This will cause the package manager to check if both dependencies in the desired version are present and, if they are missing, add them or abort with an error unless told to ignore dependencies.

Debian-style packages (.deb) on Linux, on the other hand, offer features such as:

  • Recommendations: these indicate to the package manager that only certain features of the software depend on packages listed as recommended (whereas the package is mostly useless if a dependency is missing). Depending on how the package manager is configured, recommendations can be treated as dependencies or the package can be installed without them.
  • Alternatives: for example, a package can depend on curl | wget, in which case the presence of either package alone will satisfy that particular dependency, as the software finds out at run-time which of the two is installed and works with whatever is available.

Does .pkg offer these features as well? How would these be specified in the manifest?

Improve this question

1 Answer 1

Reset to default
1

FreeBSD packages are binary packages (see pkg(7)). While you theoretically can create a bottom up binary package it would be very unusual. You would rather start with a ports(7) source based "port" and use this as the origin of your package. Even if you only have a binary source.

This is then very well documented in the FreeBSD Porter's Handbook.

You can create your own local packages if you want. If you have a vanilla FreeBSD system then the binary packages are installed from the default FreeBSD repositories. These packages are all made from the ports tree with the default config options.

You can use the command-line tools but an easy shortcut would be to browse Freshports. If we look at bind-tools we see the following defaults:

===> The following configuration options are available for bind-tools-9.18.24:
     FIXED_RRSET=off: Enable fixed rrset ordering
     IDN=on: International Domain Names support
     JSON=on: JSON file/format/parser support
     LARGE_FILE=off: 64-bit file support
====> GSSAPI Security API support: you have to select exactly one of them
     GSSAPI_BASE=off: Using Heimdal in base (nsupdate is broken)
     GSSAPI_HEIMDAL=off: Using security/heimdal (nsupdate is broken)
     GSSAPI_MIT=off: Using security/krb5
     GSSAPI_NONE=on: Disable
===> Use 'make config' to modify these settings

So if you build your port locally you can change these settings using make config. If you just want to use it locally you can do a make install. But if you want to have a binary package of this variant then simply do a make package.

If you are doing a port/package from scratch then you can see how to setup the makefile options. Notice that they can also be grouped as radio choices (as with GSSAPI above).

Common shared dependencies are usually handled with USES Macros such as Python.

Historically you made slave ports to handle invariants. But the more modern apporach it to have flavors. This is especially common with Python but please remember to be as liberal in the version selection as possible.

The architecture is then different from Debian. There are no "recommendations" as such. You would rather make the minimal viable package and then make the optional dependencies selectable in the port using options. The "alternatives" will be handled in the port again with options. Your example would then be with a radio group to allow either curl or wget. To have that reflected in your binary packages you would then create flavors.

If you want to create your own repository or are doing this as part of a CI pipeline then you should have a look at Poudiere which is the same building tool used for the official repositories.

Improve this answer
2
  • I am in fact skipping the whole binary ports part, as there is nothing to build for my package, it’s literally a matter of dropping a bunch of files from the source tree onto the target system. Creating a port, i.e. telling a build system mostly made for building native code from C sources, to copy a few files, seems like massive overkill for this use case. Even with ports I would still need separate binary packages for, say, distributions with only curl available and those with only wget, since pkg does not seem to have a way for a binary package to say “I need either curl or wget”.
    – user149408
    Commented Apr 20 at 17:10
  • Overkill?!? Minimal makefile is 8 lines for the basic info and then a plist file which lists your files. See Quick porting and simple example. You do have the option for pre/postinstall scripts. See pkg. The goal is however not clear: Distributions? FreeBSD has fetch in the base system.
    – Claus Andersen
    Commented Apr 20 at 18:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .