Initial Erlang Packaging Guidelines #1543
No reviewers
Labels
No labels
announce
bootstrap
Closed As
accepted
Closed As
duplicate
Closed As
exceptionexpired
Closed As
fixed
Closed As
invalid
Closed As
nothingtodo
Closed As
permanentexception
Closed As
rejected
Closed As
temporaryexception
Closed As
wontfix
cmake
committee
draftneeded
hasdraft
meeting
meson
needinfo
Priority
In Committee
Priority
Needs Review
Priority
Waiting For Reporter
rust
writeup
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
packaging/guidelines!1543
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "peter/guidelines:erlang"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Based on a long-standing wiki-page:
https://fedoraproject.org/wiki/User:Peter/Erlang_Packaging_Guidelines
Signed-off-by: Peter Lemenkov lemenkov@gmail.com
Thank you for your work on this! Here is some initial feedback/suggestions but note that I am not well-versed in Erlang packaging.
@ -0,0 +1,209 @@= Erlang Packaging GuidelinesNote, you need to add an entry to
nav.adocas well so this new page shows up in the navagation sidebar.@ -0,0 +1,209 @@= Erlang Packaging GuidelinesFedora Erlang SIG <erlang@lists.fedoraproject.org>:toc:The Fedora Docs theme already has a table of contents side bar, so I'm not sure that we need a second one inline.
@ -0,0 +4,4 @@:toc-placement: preamble:toclevels: 2[NOTE]This note can be removed, since once the PR is merged, this will be included in the Guidelines.
@ -0,0 +20,4 @@which can be named without the `erlang-` prefix (e.g. `couchdb`,`rabbitmq-server`, `wings`).In spec files, the short upstream name (without the `erlang-` prefix) is typicallyI would avoid standardizing on any
*namemacros and just use the literal name where it's needed in the specfiles.@ -0,0 +21,4 @@`rabbitmq-server`, `wings`).In spec files, the short upstream name (without the `erlang-` prefix) is typicallystored in a global macro for reuse throughout the spec. Both `%{realname}` andNote that following https://sembr.org is preferred for new Guidelines docs.
@ -0,0 +29,4 @@== Buildinghttps://packages.fedoraproject.org/pkgs/erlang-rebar3/[Rebar3] must be used toIt sounds like this first line should say "SHOULD be used" not "must be used", since using rebar3 is only required "whenever possible" and there is an exception for Exlixr.
I would also recommend using capitalized MUST, SHOULD, MAY, etc. in this document since we try to follow RFC 2119.
@ -0,0 +33,4 @@build Erlang packages whenever possible, as it is the de-facto standard Erlangbuild tool. If a project supports multiple build tools (e.g. both `erlang.mk` and`rebar3`), the packager must use rebar3. Projects written in Elixir may usehttps://packages.fedoraproject.org/pkgs/elixir/[mix] instead. We recommend using"We recommend" should probably be replaced with a stronger statement. It sounds like most (all?) packages should be using the macros.
@ -0,0 +42,4 @@=== Declarative BuildSystemStarting with Fedora 45, a declarative `BuildSystem: rebar3` directive is availableIs there a plan to backport this to older Fedora releases?
@ -0,0 +46,4 @@via `erlang-srpm-macros >= 0.3.11`. Its use is recommended for new packagestargeting Fedora 45 and later, but is not yet required.[NOTE]@carlwgeorge can chime in here, but I think there we are trying to avoid EPEL-specific notes in the main Fedora Packaging Guidelines.
Yes, the packaging guidelines are intended to assume Fedora Rawhide, stable release notes are occasionally acceptable, EPEL documentation needs to go elsewhere.
@ -0,0 +70,4 @@Erlang packages should be installed to `%{_erllibdir}/%{realname}-%{version}` (orequivalently `%{_erllibdir}/%{srcname}-%{version}` depending on which macro thespec uses). The handy macro `%{erlang_appdir}` has been provided as a shorthand(This comment is somewhat opinionated feedback, and I do not consider it a blocker here.)
See my above note about standardizing on
*namemacros. I'm not a huge fan and have removed this convention from the macros I maintain in favor of having the macros/packaging scripts read project metadata and determine the correct name from there.The Python macros (
%pyproject_save_files, which is run in%install, and%pyproject_files, which is a path to a file list populated by the first macro is included with%files -f %{pyproject_files}) are examples of populating%fileswithout requiring global name macros.@ -0,0 +87,4 @@== DependenciesErlang packagers need to build the list of `BuildRequires` by hand, but RPM buildsAre there plans to adopt
%generate_buildrequiresfor erlang?@ -0,0 +104,4 @@sudo dnf provides "*/lager.beam"----== ChangelogThis probably doesn't need to be part of the erlang Guidelines since it is already covered by the general Guidelines and not specific to erlang packaging.
@ -0,0 +130,4 @@License: Apache-2.0URL: https://github.com/awesomeperson/%{realname}VCS: git:%{url}.gitSource0: %{url}/archive/%{version}/%{realname}-%{version}.tar.gzIt's not necessary to number sources anymore.
@ -0,0 +136,4 @@# extra packages are required — check the Koji build log for hints.BuildRequires: erlang-rebar3# RPM detects Erlang dependencies automatically when built with rebar3.What are those special cases? Should they be documented in the Dependencies section?
@ -0,0 +147,4 @@%autosetup -p1 -n %{realname}-%{version}%build%{erlang3_compile}Generally, macros that invoke a command are called without the curly brace syntax:
Same applies elsewhere.
@ -0,0 +129,4 @@Summary: Erlang library for doing cool thingsLicense: Apache-2.0URL: https://github.com/awesomeperson/%{realname}VCS: git:%{url}.gitIs specifying
VCSrequired by the erlang macros? There are not Guidelines about using or not usingVCSin Fedora (as far as I know) and its presence in the examples may be confusing if it's not a requirement.Yes, please don't specify
VCS:.Key points: - rebar3 is the required build tool; rebar2 is deprecated - %erlang3_compile/%erlang3_install/%erlang3_test macros are mandatory - BuildSystem: rebar3 declarative form available in F45+ only - RFC 2119 terms used throughout (MUST, SHOULD, MUST NOT) Known limitations and future work: - %{realname}/%{srcname} macros are currently used in practice across Fedora Erlang packages for scripting purposes. Both are acceptable for now; a better solution derived from %{name} or extracted from rebar.config is under consideration. - %generate_buildrequires support for Erlang is not yet implemented. A future improvement could auto-generate BuildRequires by parsing rebar.config dependencies, similar to what pyproject-rpm-macros does for Python packages. Signed-off-by: Peter Lemenkov <lemenkov@gmail.com> Assisted-by: Claude (Anthropic) <https://claude.ai>View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.