search

ZcashFoundation / zebra

Zcash - Financial Privacy in Rust 🦓
https://zfnd.org/zebra/
Apache License 2.0
408 stars 100 forks source link

Investigate creating a Debian package for zebra #6422

Open mpguerra opened 1 year ago

mpguerra commented 1 year ago

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 commented 1 year ago

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:

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 commented 1 year ago

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

mpguerra commented 1 year ago

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

str4d commented 1 year ago

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

gesker commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

teor2345 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

2. Debian Control Files

3. Binary and Library Paths

4. Documentation and Man Pages

5. Licensing

6. Versioning

7. Build Process

8. Testing

9. Static vs. Dynamic Linking

10. Configuration Files and Data

11. Init Scripts and System Services

13. Maintainer Scripts

14. Package Testing

16. Repository Considerations

teor2345 commented 1 year ago

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 commented 1 year ago

Perhaps Debian Backports would be suitable?

teor2345 commented 1 year ago

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 commented 1 year ago

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