[go: up one dir, main page]

Build: Introduce beta build scripts for Debian package format (dpkg) and Redhat package format (rpm) into tree

Chris Pinnockrequested to merge
chrispinnock@pkg into master

Context

It is desirable to maintain official Octez packages that can be released on the same day as the source code and docker images for Octez releases. I have been working on these packages as a side-project to support work on my personal Tezos articles and the Tezos Foundation GCP partnership project. Also I did this to provide some co-bakers with Raspberry Pi packages.

There are of course community packages as well.

The client, node and baker packages are in use on the Tezos Foundation GCP boot, archive and VDF nodes. I personally use them on Raspberry Pi and on another Ubuntu machine. To date, I have been building packages on Debian 11, 12, Ubuntu 20 and 22, RPi Linux. They can be found here: https://pkgbeta.tzinit.org/

(In my builds I have been including the os name and "unoff" for unofficial - we will not do this if this goes forward).

The scripts build a binary footprint and then build a binary dpkg/rpm. I have decided to do this instead of source packages (which is probably the right way) because:

  • it works with the prescribed developer build process (get rust, install deps, make build-deps, make, etc)
  • it integrates into the current developer experience
  • therefore a developer will be able to build packages if they need them of their branch

The only place this work touches the main Octez work is in the Makefile to add targets dpkg, rpm, dpkg-clean, rpm-clean and alter the clean target to also run dpkg-clean, rpm-clean. I have not added automatic testing at this stage.

Manually testing the MR

  • Make tezos as normal (make build deps; eval opam env; make)
  • Set an environment variable OCTEZ_PKGMAINTAINER to something suitable (e.g. pkgmaster@nomadic-labs.com)
  • Build Debian packages "make dpkg"
  • Build RPM packages "make rpm"

The process will complain (but not exit) if BLST_PORTABLE is not set in the environment. Tezos needs to be built with this to guarantee portable packages.

Checklist

  • Document the interface of any function added or modified (see the coding guidelines)
  • Document any change to the user interface, including configuration parameters (see node configuration)
  • Provide automatic testing (see the testing guide).
  • For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
  • Select suitable reviewers using the Reviewers field below.
  • Select as Assignee the next person who should take action on that MR

Merge request reports