The versions of rebar in portage are very out of date and are deprecated. The referenced package may need to be removed from the tree, the updated version is now called rebar3. https://www.rebar3.org/
IMHO, rebar3 should be added as a new package. If you're interested, please get in touch with proxy-maint! I'm dropping maintainership of dev-util/rebar and don't have time for rebar3, either, so I'm closing this.
Why do you think rebar3 should be added as a new package? I think we can leave this open unless there is a reason why we do not want this package in the tree in general. Interested users may try to prepare an ebuild in the mean time. Here is, how other distributions do it https://repology.org/metapackage/rebar3/versions Is dev-util/rebar-2.x still usable? @R030t1 are you using this software and are you able to prepare an ebuild?
dev-util/rebar3-3.6.1 and a corresponding "rebar3" eclass are available in my overlay: https://github.com/stefantalpalaru/gentoo-overlay It's important to note that it's not a drop-in replacement for rebar-2.x. I tried to use it that way and it failed to compile a recent https://github.com/processone/p1_utils
Stefan, how do you handle deps? Doesn't bootstrap try to fetch any deps?
I've looked briefly at boostrap and rebar.config. Deps: https://github.com/erlang/rebar3/blob/master/rebar.config#L4 and https://github.com/erlang/rebar3/blob/master/bootstrap#L14 We cannot fetch stuff in src_compile or src_prepare.
It does. It fetches, compiles, links and packages those deps in the resulting "rebar3" binary that is actually a zip file with a three-line script header calling "escript". Run "unzip -l rebar3" to see the listing.
I don't think it's acceptable. Perhaps the easiest way would be to go with rebar3-bin. They do publish rebar3 binary, don't they?
Yes, they do: https://github.com/erlang/rebar3/releases It looks like the same zip archive you get when building from source (if using the same Erlang version to generate the bytecode).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1efa3958413cda09142e12371e54032a9c442e17 commit 1efa3958413cda09142e12371e54032a9c442e17 Author: Amadeusz Piotr Żołnowski <aidecoe@gentoo.org> AuthorDate: 2018-10-24 22:23:19 +0000 Commit: Amadeusz Piotr Żołnowski <aidecoe@gentoo.org> CommitDate: 2018-10-24 22:26:59 +0000 dev-lang/rebar-bin: Add new package Fetch and install prebuilt binary as it's way easier than building this from source. Bug: https://bugs.gentoo.org/628876 Signed-off-by: Amadeusz Piotr Żołnowski <aidecoe@gentoo.org> dev-util/rebar-bin/Manifest | 1 + dev-util/rebar-bin/metadata.xml | 28 ++++++++++++++++++++++++++++ dev-util/rebar-bin/rebar-bin-3.6.2.ebuild | 31 +++++++++++++++++++++++++++++++ 3 files changed, 60 insertions(+)
OK, next thing would be to update eclass. I see the way that user of eclass defines REBAR_VERSION=2 or REBAR_VERSION=3 and erebar function uses either rebar or rebar3 depending on value of this variable.
diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass index f2a620fd8979..cbae1905af91 100644 --- a/eclass/rebar.eclass +++ b/eclass/rebar.eclass @@ -42,6 +42,11 @@ DEPEND="${RDEPEND} # Relative path to .app.src description file. REBAR_APP_SRC="${REBAR_APP_SRC-src/${PN}.app.src}" +# @ECLASS-VARIABLE: REBAR_VERSION +# @DESCRIPTION: +# Which version of rebar to use: 2 or 3. Default is 2. +REBAR_VERSION="${REBAR_VERSION-2}" + # @FUNCTION: get_erl_libs # @RETURN: the path to Erlang lib directory # @DESCRIPTION: @@ -105,7 +110,11 @@ erebar() { (( $# > 0 )) || die "erebar: at least one target is required" local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)" - rebar -v skip_deps=true "$@" || die -n "rebar $@ failed" + + case "$REBAR_VERSION" in + 2) rebar -v skip_deps=true "$@" || die -n "rebar $@ failed" ;; + 3) rebar3 -v skip_deps=true "$@" || die -n "rebar3 $@ failed" ;; + esac } # @FUNCTION: rebar_fix_include_path
Sounds good. Don't forget to change it to "[[ -d ebin ]] && doins -r ebin" in rebar_src_install() because that dir is optional with rebar3. You also need to change the injected DEPEND.
It compiles into some _build subdirectory, at least dev-erlang/meck. src_install phase will need some changes as well. I'll have a look few days later. Feel free to investigate in the meantime.
Yes, that's a start, only. Feel free to provide a patch, as I need to park this for few days.
(In reply to Amadeusz Żołnowski from comment #5) > We cannot fetch stuff in src_compile or src_prepare. (In reply to Amadeusz Żołnowski from comment #7) > I don't think it's acceptable. Perhaps the easiest way would be to go with > rebar3-bin. Using rebar binary is not enough to avoid fetching stuff in src_compile or src_prepare. When running `rebar3 compile` to compile a package, rebar fetches and compiles necessary plugins first, and then it compiles the package. I don't have any ideas on how to handle rebar plugins. They can't be installed system-wide.
BTW the latest version now is 3.11.1.
Doesn't seem Hanno ever maintained this package.. assigning to m-n and changing version to latest.
