Erlang versions 19.0.1->19.0.5 are patch packages rather than full releases, but they do contain bugfixes. Attached is an ebuild for 19.0.5, along with the incremental patches for 19.0->19.0.1 through 19.0.5.
Created attachment 443992 [details] erlang-19.0.5.ebuild
Created attachment 443994 [details, diff] erlang-19.0.1-to-19.0.2.patch
Created attachment 443996 [details, diff] erlang-19.0-to-19.0.1.patch
Created attachment 443998 [details, diff] erlang-19.0.2-to-19.0.3.patch
Created attachment 444000 [details, diff] erlang-19.0.3-to-19.0.4.patch
Created attachment 444002 [details, diff] erlang-19.0.4-to-19.0.5.patch
Ugh. What's so hard about putting out a full tarball?
(In reply to Dirkjan Ochtman from comment #7) > Ugh. What's so hard about putting out a full tarball? I have no idea. When making the diffs from the git tags, I had to remove some changes to stuff in $ERL_TOP/bootstrap introduced in 19.0.2, as it seems that the stuff in bootstrap isn't used when building from the source tarball.
Can we just take the 19.0.5 tarball from GitHub? I guess that would leave the documentation outdated... I kind of don't want to deal with this patch crap.
(In reply to Dirkjan Ochtman from comment #9) > Can we just take the 19.0.5 tarball from GitHub? I guess that would leave > the documentation outdated... I kind of don't want to deal with this patch > crap. By the "GitHub tarball" do you mean the zip file that's linked by the "Clone or Download" button for the currently viewed branch/tag: https://github.com/erlang/otp/archive/OTP-19.0.5.zip ? Also, I'm happy to keep watching the erlang-questions mailing list for "patch package" announcements and making the relevant patches and ebuild changes.
(In reply to Kenneth Lakin from comment #10) > Also, I'm happy to keep watching the erlang-questions mailing list for > "patch package" announcements and making the relevant patches and ebuild > changes. I had forgotten that I could ask GitHub to create diffs for me: ( https://github.com/erlang/otp/compare/OTP-19.0.4...OTP-19.0.5.patch ). If you're willing to let me do revision bumps for "patch releases", this will make it easier for you to verify that I'm not doing anything incorrectly or maliciously.
The 19.0.6 and 19.0.7 patch packages were released today. It looks like .7 was released to ship a fix that was left out of .6, so I'm only posting the 19.0.7 ebuild. 19.0.6 patch package announcement: http://erlang.org/pipermail/erlang-questions/2016-September/090120.html 19.0.7 announcement: http://erlang.org/pipermail/erlang-questions/2016-September/090129.html .5 to .6 patch is from here: https://github.com/erlang/otp/compare/OTP-19.0.5...OTP-19.0.6.patch .6 to .7 patch is from here: https://github.com/erlang/otp/compare/OTP-19.0.6...OTP-19.0.7.patch I've asked about the patch package vs. full release policy. It _looks_ like micro version bumps (ie .6 to .7) get patch packages, while minor or major version bumps get full releases. That thread starts here: http://erlang.org/pipermail/erlang-questions/2016-September/090135.html
Created attachment 445760 [details, diff] erlang-19.0.5-to-19.0.6.patch
Created attachment 445762 [details, diff] erlang-19.0.6-to-19.0.7.patch
Created attachment 445764 [details] erlang-19.0.7.ebuild
Created attachment 447264 [details] erlang-19.1.ebuild Erlang 19.1 has been released. Since this is a full release, there's a release tarball and everything. This ebuild is virtually identical to the erlang-19.0 ebuild. The only thing changed is an off-by-default USE flag (dirty-schedulers) which enables dirty schedulers. I'll attach the modified metadata.xml next.
Created attachment 447266 [details] metadata.xml
Committed this: commit eb36a77d6c29fabbbcd2471b4df7fd44c19db412 Author: Dirkjan Ochtman <djc@gentoo.org> Date: Sat Sep 24 10:52:11 2016 +0200 dev-lang/erlang: version bump to 19.1 (fixes bug 591970) Thanks to Kenneth Lakin <kennethlakin@gmail.com> for doing the work. Package-Manager: portage-2.2.28 Thanks for doing the work! And sorry for not being able to accomodate the patch releases, I just think not releasing tarballs is a boneheaded upstream policy.
(In reply to Dirkjan Ochtman from comment #18) > Thanks for doing the work! No problem. I'm happy to do it. Glad the new version made its way into the tree. > And sorry for not being able to accomodate the patch releases, > I just think not releasing tarballs is a boneheaded upstream > policy. I understand your opinion on the matter. However, upstream is not likely to budge. Looking at the erlang-questions mailing list history, it seems that they've been doing things this way for a long time. Meanwhile, Gentoo users miss out on bugfix releases. For reference, the project's versioning scheme is laid out here <http://erlang.org/doc/system_principles/versions.html#version_scheme>. The salient parts for the purposes of this discussion are as follows: " In the normal case, a version is constructed as <Major>.<Minor>.<Patch>, where <Major> is the most significant part. ... The three normal parts <Major>.<Minor>.<Patch> are changed as follows: * <Major> - Increases when major changes, including incompatibilities, are made. * <Minor> - Increases when new functionality is added. * <Patch> - Increases when pure bug fixes are made. " Given that upstream isn't going to change their release tarball policy, what needs to be done to ensure that Erlang's patch releases start reliably making their way into the Portage Tree? I'm happy to do the legwork required to create patches (or -I guess- download GH zip files), build and do smoke testing for these releases on x86 (for as long as my 32-bit machine keeps running) and amd64. If you need me to become a Gentoo Developer and take over maintenance of this package, I could do that, too. (Though I hear that that process takes quite a while.)
Well, we're always happy to have more devs anyway, so if you're at all interested, that sounds like a good avenue to explore. It does usually take a while, though. I'm not really a heavy erlang user, I only maintain it because I like to use CouchDB. Since I'm pretty busy with other stuff, dealing with upstream idiosyncracies in how they do their micro releases is really something I can do without, but let's see what happens with 19.1 patch releases.
