erigon
erigon copied to clipboard
Adding debian packaging
The PR does the following:
- Introduces a simple debian packager for x86/amd64 and arm64
- Creates the required service file for systemd control with the packages
- postrm and postinst for proper install and removal of the package.
Uses the /opt/erigon location for data, this can be changed, using this approach is more in line with *nix standards for optional software packages location.
some questions:
- to publish deb package we don't need any public key? if no - then anybody can publish under our name?
mainwe pushing there every day - is it ok?- i see it using make erigon to build binary, but then to cross-compile it doesn't use make - it means all flags we have in Makefile was lost for cross-compiled binaries. Example1:
CGO_CFLAGS += -D__BLST_PORTABLE__, Example2:-trimpath -tags $(BUILD_TAGS) -buildvcs=false(whereBUILD_TAGS = nosqlite,noboltdb) - need add
workflow_dispatch:to .yml - to allow manual run of flow (like on this picture https://github.com/ledgerwatch/erigon/issues/7893 ) - (not for this PR, but in-general): why only erigon and no rpcdaemon, etc... (if we will build all binaries this way, likely .yml will get 1K lines. maybe not)
- To publish to official debian package repo you do need a public key and it is an entier approval process. Most do not do this, they setup their own PPA/Package repo as it is far easier and less tedium than the requirements.
- We can change the target branch, I used main as it was what I used for the testing and similarly we use that as the basis at Polygon for bor/heimdall.
- I can add changes to use the Makefile, the scope of what I was working on was creating an erigon binary to be used with ansible and profiles.
- I can and will add, do you have any requirements and or custom defined inputs you would like for this addition?
- See 3, but if you would like we could schedule a call/chat via slack and discuss further
- what repo used in this PR?
- main is fine
- yes, use makefile fine
- no. empty is fine. you can see in ci.yml
- no. i think we are almost fine.
@AskAlexSharov
- Official Debian/Ubuntu repos are controlled by their respective maintainers and the project would be asked to join those. Otherwise you could/would use a PPA model or hosted a dedicated repository. These packages introduced in this PR would be available for each tag built within artifacts.
- Awesome
- Ok, updating that in the next day or so, been swamped with some other tasks.
- 👍
- 👍
Performing a few more test sand will update this PR to reflect the changes to makefile and processes. Should wrap this up in a couple of days. Pardon delay.
@lystopad assigned to you. Just check: 1 - can it be inserted as a portion of the new workflow you're developing? If it can, I suggest that to be done at a later stage (so that this is conveniently tested as a standalone workflow before merging it to yours) 2 - on dispatch for manual runs 3 - a dedicated debian repo would be more convenient for us? 4 - only erigon? what about downloader and all the other binaries?
Hi, all. Thank you for your efforts and great work.
@djpolygon , @AskAlexSharov, @yperbasis -- I am going to implement it in our release workflow later. At the moment I am working on intermediate stage in the release workflow. Once my work will be done, I can add debian package stage to the workflow.
Best regards @lystopad
@lystopad there's also some linux package of erigon created by Eddy, who used to work with us: https://github.com/erigontech/erigon-pkg
@errge, @djpolygon hi! Thank you for your efforts.
I created https://github.com/erigontech/erigon/issues/12891 for me and will use it to track my changes. Unfortunately, this PR could not be merged and used AS IS. Sorry for that. In our case debian package build workflow should be a part of release workflow, taking into account some other coming changes in the release workflow.
I hope, we will release debian packages with coming 3.x release.
Thank you so much for your great work.