-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Distro and Packaging README FAQ
Work in Progress -- to be discussed by FRR maintainers and/or TSC
This document is the primary reference-point for distributions, package-builders, and people who build customised packages for large environments (e.g. clouds). It is organised as FAQ, but please scroll through the entirety of it.
Two reasons:
- When you make a package for e.g. 2.0, it is still relevant to see what direction >=3.0 are moving to.
- A file in git would presumably be in the tarball, be frozen at release time, and become outdated.
Please call the package (and service names / init scripts / users / groups ...) just frr. It's our official "short name" and all of our documentation will refer to that as service/init/user/group name. If you rename it (e.g. to "frrouting"), we will point all confused users to you ;)
https://lists.frrouting.org/listinfo/announce You can also subscribe to github notifications on new tags, but there may be occasional non-release git tags.
https://github.com/FRRouting/frr/releases "dist" tarballs are as additional github binary blobs on the tags. ("Source code" is GitHub's automatic thing; "frr-X.X.tar.xz" is the dist tarball.)
Please use the GitHub issue tracker: https://github.com/FRRouting/frr/issues
TBA (integrated-config)
FRR is moving in a direction where the integrated supervision daemon, watchfrr, is becoming increasingly more relevant. This is for 3 reasons:
- watchfrr does lively checks on the daemons, killing them if they hang
- watchfrr is required for correct operation of integrated-config mode (watchfrr will write the integrated config when requested by the user; without it, permissions and ownership of the file will be wrong and cause breakage)
- the set of running daemons is becoming increasingly configuration-determined
The latter part is really why we're putting this into watchfrr; a router ospf 5 command in the configuration or live shell needs to start a new ospfd process for instance number 5, and watchfrr is the piece that will handle this.
As a result of this, the recommendation is to use a single service / init script for FRR. Since watchfrr in current versions still expects a list of daemons to start, this means there needs to be a frr.defaults-like file that specifies which daemons to start.
(Please call the service/initscript frr, that's what we'll be using in all documentation.)
You can package the daemons separately, but the only use of this is saving a few bytes on embedded distributions. We do not currently manage a stable ABI for any of the shared libraries. If you split the package, you need to ensure versions always match exactly between all subpackages.
Starting with FRR 3.0, several pieces have been broken out into loadable DSOs. This is notably:
- SNMP support
- FPM interface (with protobuf support)
The intention here is to push the dependencies for Net-SNMP and Protobuf into their own packages, installable independently by the user. Therefore, we'd recomend that you put these .so files into their own packages.
The historic SNMP OpenSSL-vs-GPL license issue had been fixed by stripping OpenSSL from Net-SNMP's linked library list, it is also a non-issue now with OpenSSL's Apache 2.0 license since you can distribute FRR under GPL version 3.
The options that control building these modules do not have any impact on the main package; you can build pieces separately in separate runs if you want to.
First, you can look at https://github.com/FRRouting/frr/tree/master/doc for Building_FRR_on_... files. They contain general documentation made by our main test engineer and are very helpful :)
In general, we'll update configure's defaults to match what we think are good defaults. There is also some documentation in https://github.com/FRRouting/frr/blob/master/doc/install.texi. There are some options you should not use, notably:
-
--enable-dev-build. This enables additional debugging code that is intended for development use only. It may arbitrarily crash and may contain security holes. We won't be putting out advisories if we find problems in these pieces. -
--enable-werror. This should be part of distribution policy -- don't make package builds with-Werror. The point of it is that we use it in development so we're forced to fix warnings, but we can't anticipate future warnings (or current warnings in configurations we haven't covered), and a simple compiler warning shouldn't cause a package build failure.
Generally, we're trying to cut down on the number of configure options to make the package and its feature set more consistent.