Investigate creating a Debian package for zebra

[mpguerra]

Motivation

In order to make it as easy as possible for users to install and run zebra in the most popular operating systems we might want to consider creating a Debian package for Zebra

Scope

This issue is related to research the necessary steps, infrastructure and artifacts as well as required ongoing maintenance with the end goal of reaching a decision on next steps. It is not about creating the actual package.

[teor2345]

In order to create a Debian package for Zebra, we might need to:

1. Locate or create Debian packages for Zebra's required OS library dependencies
2. Deploy a Debian package server in our production server environment
3. Create Debian package signing keys and put the public keys on the server
4. Create Debian packaging scripts in the Zebra repository
5. Run the whole Debian build after every release and upload the packages to the server

If we stick strictly to Debian's packaging policies, we would need to have a much larger first step:

• Locate or create Debian packages for all of Zebra's Rust, C/C++, and OS library dependencies

But we can break some of the Debian policies when we're using our own server. (We can't use a Debian server because network upgrades are less than 3 years apart, and Debian expects stable packages to only have bug fixes during the supported lifetime of each Debian version.)

The alternative is to tell people on Debian "install Docker and use the Zebra Docker images".

[mpguerra]

I think we might want to do this after the stable release.

[mpguerra]

Documentation from debian on this process: https://www.debian.org/doc/manuals/developers-reference/pkgs.html

[str4d]

The cargo-deb crate will likely be useful for this. You can see an example of using it with my rage crate here:

• https://github.com/str4d/rage/blob/main/rage/Cargo.toml
• https://github.com/str4d/rage/blob/main/.github/workflows/release.yml

[gesker]

Will the Debian package use the Filesystem Hierarchy Standard? Meaning will the chain data be stored under /var, configs under /etc and have a systemd entry?

Any chance the Debian package will have an option to run on BOTH test net and main net at the same time? Or, launch twice so that test net can be accessed?

My systemd files and notes are here - if that is useful for this item - BUT they are pointing to my home directory as I've just been building from source.

In any event thank you for making a deb package! This will be great. And, a great option for anyone having spare capacity to run a node.

[teor2345]

@gesker we haven't decided exactly what's going to be in the package yet, so thanks for this feedback!

We're also trying to decide how urgent this ticket is, so we can schedule it. Are there specific things you can do with a Debian package that are harder with Docker?

(We already have a Docker package.)

[mpguerra]

Hey team! Please add your planning poker estimate with Zenhub @arya2 @gustavovalverde @oxarbitrage @teor2345 @upbqdn

[teor2345]

This is potentially a very large ticket, and its scope isn't really defined yet. I suggest we investigate what's needed first, then split this ticket into multiple tickets, and estimate them.

[upbqdn]

I based my estimate on the scope in the description above:

Scope

This issue is related to research the necessary steps, infrastructure and artifacts as well as required ongoing maintenance with the end goal of reaching a decision on next steps. It is not about creating the actual package.

[teor2345]

I based my estimate on the scope in the description above:

Scope

This issue is related to research the necessary steps, infrastructure and artifacts as well as required ongoing maintenance with the end goal of reaching a decision on next steps. It is not about creating the actual package.

Thanks for the reminder! I guess I skimmed that bit, and mainly looked at the title, which was a bit unclear to me. Previously I've seen us submit actual working PRs in response to tickets like this.

So @mpguerra what's the output of this ticket? Is it a list of tasks, a detailed proposal, or something else?

[gustavovalverde]

Is it a list of tasks, a detailed proposal, or something else?

We should basically investigate and create a list of tasks and considerations similar to what you've shared here: https://github.com/ZcashFoundation/zebra/issues/6422#issuecomment-1487738572

This is part of the list (so far):

1. Choose the Packaging Tools

• cargo-deb: A Rust crate that generates Debian packages from Cargo metadata.
• dh-cargo: A helper tool to streamline packaging Rust programs/libraries with debhelper.

2. Debian Control Files

• control: Contains package metadata like dependencies, maintainer, description, etc.
• rules: Specifies commands to build, install, and clean the package.
• changelog: Logs version numbers, changelists, and other details.
• compat: Indicates debhelper compatibility level.

3. Binary and Library Paths

• Ensure compiled binaries are installed in paths like /usr/bin/.
• Shared libraries should go in paths like /usr/lib/.
• Use the Filesystem Hierarchy Standard (FHS).

4. Documentation and Man Pages

• Include documentation, READMEs, or man pages for users.

5. Licensing

• Comply with Debian's licensing guidelines (?).

6. Versioning

• Debian package version may differ from Zebra's crate version.
• Understand Debian's versioning scheme.

7. Build Process

• Define the build process in the rules file and use Cargo for compiling.

8. Testing

• Consider running crate tests during the packaging process (?).

9. Static vs. Dynamic Linking

• Rust statically links by default. Decide if this is suitable or if dynamic linking is better.

10. Configuration Files and Data

• Configuration files typically go in /etc/.
• Data files can be placed in /usr/share/.
• Blockchain data can be stored under /var.

11. Init Scripts and System Services

• Consider including init scripts or systemd service files.

13. Maintainer Scripts

• Consider scripts like preinst, postinst, prerm, postrm which run before/after installation and removal.

14. Package Testing

• Test the installation, removal, and any post-installation scripts on a clean Debian system.

16. Repository Considerations

• Consider creating Release and InRelease files and signing packages.

[teor2345]

If we're running our own debian server, these steps might be optional:

5. Licensing

* Comply with Debian's licensing guidelines (?).

6. Versioning

* Debian package version may differ from Zebra's crate version.
* Understand Debian's versioning scheme.

...

9. Static vs. Dynamic Linking

* Rust statically links by default. Decide if this is suitable or if dynamic linking is better.

I don't think we can use Debian's servers, because we make an incompatible upgrade every 6-12 months, but Debian releases require software to work and be feature-stable for at least 3 years. (The Debian release lifetime.)

It might be possible to use Debian's testing server, and perpetually be in testing, I'm not sure. And the testing Debian release might not meet our stability or Debian release compatibility goals.

What Debian releases do we intend to support?

[gesker]

Perhaps Debian Backports would be suitable?

[teor2345]

Perhaps Debian Backports would be suitable?

I think the Backports stable version policy would prevent us from having Zebra in Backports:

To guarantee a clean upgrade path from one Debian stable release to the next, packages in Backports cannot be newer than the packages destined for the next Debian stable release; this is a matter of Backports Policy.

I also think it might be confusing to have a package in stable that doesn't work, or a package in testing that never graduates to stable.

And the stability guarantees of next-stable might make it difficult for us to reliably build the package: https://wiki.debian.org/DebianTesting

I think our best bet here is to do what ECC does with their Debian packages, and run their own server.

[mpguerra]

I think we can close this one once we have a good first list in #7424