Octez debian packages are currently in master, compiled by the CI, and were released with Octez 19. This is a a follow-up of %Octez packages

Because of external factors, these packages were developed accumulating a good amount of technical debt.

From a technical prospective, the packages are created using a bash script instead of following the best practices of building debian packages and without reusing the large set of tools at our disposal to build and distribute debian packages.

This Milestone wish to tackle a few issues:

• Use systemd services instead of init.d bash scripts to run octez.
• Consistently use logrotate for all octez services.
• Remove all bash scripts and we use the standard way of packaging binaries for debian.
• Ship all packages using a signed apt repository using gilab.io as storage.
• Provide build images containing all the needed build dependencies (system and opam packages) for debian stable and unstable to speed up compilation time.
• Provide packages for both amd64 and arm64 architectures, paving the way for all supported architectures by debian using qemu.

There are a number of other features in the work

• Include a debconf helper script in each package to tailor the installation for different users’ profiles
• Allow for a smooth transition between the current packages and the new packages
• Create a pre-seed profile for automatic and unsupervised installations using debconf.

And for future work ( not for this milestone )

• Add a debian source package so to empower rebuilders to build and verify our packages
• Add more architectures
• Ambitious: inclusion in debian contrib

Roadmap

Debian packages were released in v19, we need to consider a roadmap to transition for the “old”, but officially released packages and the new ones.

We need to make sure of a smooth upgrade path, to make sure we do not break anything in existing infrastructures.

Since we have complete control on the code, the proposed solution is to work on a convergence path, where the old packages will be adapted to work as the new packages and therefore propose a smooth upgrade path.

Timeline

• Update documentation for packages, phasing out third party packages and introduce Nomadic's packages ( !13273 (merged) ).
• Start working on the old packages to create a convergence path the new packages ( mainly adapting variable names and paths ).
• Introduce the new package for Octez-node, client in the +1 release as artifacts ( !11693 (merged) )
• Introduce new packages for the baker, signer ( !12020 (merged) )
• Introduce new packages for octez-smart-rollup ( !12357 (merged) )
• Introduce new packages for octez-dal ( !12704 (merged) )
• Add multi arch / multi OS support ( !11706 (merged) )
• Introduce new packages for all experimental binaries ( !13037 (merged) )
• Start deprecating the old packages in favor of the new ones ( !14090 (merged) ).
• Unofficial release and testing of the new packages using the apt repository instead of the gitlab package registry ( !12637 (closed) , !13697 (merged) !14115 (merged) )
• Publish a detailed documentation on how to use these packages ( https://hackmd.io/qwid55dJSd6R6AnvcyEKKQ?view draft )
• Test upgrade with the new packages
• Release +2 removal of the old packages and make the new packages the official Nomadic Labs packages.
• Make the packages official in the documentation (blog article ?)

Since this milestone spans over the time frame of two octez releases ( maybe more ), it's difficult to estimate the exact end date. From a technical prospective, the work will be finished long before it can be merged and released.

Large part of this work was already prototype here: https://gitlab.com/nomadic-labs/tezos/-/merge_requests/655

Risks

• Alienating users if the upgrade is not smooth
• Once the old packages are released we will see many people trying. Depending on the quality of these packages and the users’ adoption rate we might see many reports. Hopefully the packages will be well received.
• Try to make the packages as easy to install as possible. We need to talk with different users and how they use octez to determine the best way to configure and install the new packages.