From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 25CB1139337 for ; Mon, 26 Jul 2021 07:17:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7306BE0A5E; Mon, 26 Jul 2021 07:17:46 +0000 (UTC) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 938E1E0A5E for ; Mon, 26 Jul 2021 07:17:45 +0000 (UTC) Received: by mail-vs1-xe33.google.com with SMTP id 5so4689027vsd.11 for ; Mon, 26 Jul 2021 00:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=p4jPIBXozRo8mG6XtWPcIImxQvhfH6Af40gNraXAIMQ=; b=KxOjOKksNBFWkLvubVtCXJ/6EBxdwdhCqomAg8kPcWCSZQ9PH0lTmFJIwtNtYuVEbO 8VuB1OjE96Y/MqaHCH2LpT09TzFg3IXSFQ+TgI5VY8+Rwte7fO/z0VpoFOj0olsx94T/ PamUvNONamG6oCK3Hxt/wGh/d7aYiaUeLF4g9aj0un3vEWQ/I0VEmhK7UkHljiqXIJma 0S7GpglXzNcDlpy2mvkii20Yfx8/SuGH6Ub5uU55Rz+M7etYTjMuVBVunivrL0iivezu /qRzZRA64TyYRu6yTzgeJegrM/X56jaVw8Pdn0Tp+dHGPkVIruJ/Nd6uknFWNRaHpxO7 FaXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=p4jPIBXozRo8mG6XtWPcIImxQvhfH6Af40gNraXAIMQ=; b=j+VBUMuOcTE7QojCXF/I7hudvHAgFRiZu6tW3IT/kTg4pVZXxqE3Oq9U59K3FRWFx5 2P5zglUpbiDzAHsJxEux+OSCOj8Hu/rPWtTkdaWS16PORFJdL9ojCHft8XXPAzffuYC8 Wf9KXDhVrq/VsmSLajUgRDwijGB+o1E99/bchrupAitOBRjVawffDudMTNdBjdxqLd5S 0/hfmhBH8o9aRwDDme5I+g1Ia1hiX2zoVvXbx9a6PwNPhCc0DjNIT1hoN7eRycMigvqB snHvxGtjlr+TVP2Ly1QP78hND8cK8bQagWvpQbCWx9j6PmZXyKHLzM0aacbG09TNebvs 8iMw== X-Gm-Message-State: AOAM530QLr32oFo38A5pkSBUlZsN37puHqOvZdEE583Cf71EpsWLKAM8 I1/cyQp7luvs5HoXRmPpcPQI4hJHy+lGs01iQTM5oxM/xhY= X-Google-Smtp-Source: ABdhPJxpqUjwlS+aueLnR8mnK1uHnWXZ7VQzLX+1tTjWv8yeIaKNRjIDl3wsynoGnEaqUJ52bwW0IJOnp8GNBF4QXwA= X-Received: by 2002:a05:6102:ec9:: with SMTP id m9mr11540983vst.5.1627283864439; Mon, 26 Jul 2021 00:17:44 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 From: "Yuan Liao (Leo)" Date: Mon, 26 Jul 2021 00:17:08 -0700 Message-ID: Subject: [gentoo-soc] Week 7 Report for Big Data Infrastructure and H2O ebuilds Project To: gentoo-soc@lists.gentoo.org Content-Type: multipart/alternative; boundary="000000000000b04f1f05c8018c4b" X-Archives-Salt: a422a8d5-a6d2-4263-939e-6b698f02674b X-Archives-Hash: 789355776bd4853d0a29202b241ef0ef --000000000000b04f1f05c8018c4b Content-Type: text/plain; charset="UTF-8" Hi folks, Another week has just passed. I have been gradually moving on to the next part of my project where I would fix the ebuilds in the Spark overlay that are no longer installable, most of which are caused by changes to ebuilds in the Gentoo repository since last year's GSoC concluded. At the same time, a few additional utilities supporting Kotlin on Gentoo have been created, including an eselect module for Kotlin [1] and some new Kotlin eclasses. Many ebuilds in the Spark overlay depend on packages in ::gentoo, but some dependencies have been broken due to removal of old slots or even deletion of packages that were really too old. In the former case, the dependency could be quickly fixed by updating the slot, although the dependee package would require some integration tests with the dependency's new slot. In the latter case, I would restore the removed ebuild from the Git history of ::gentoo and add it to the Spark overlay. This is probably not the best resolution, but as the number of packages in the Spark overlay may suggest, Apache Spark is a complicated program whose dependency graph spans hundreds of libraries, so recreating each ebuild removed from ::gentoo from scratch might take too much time. However, the ebuilds were not restored willy-nilly. ebuilds that used EAPI 5 were ported to EAPI 7, the latest EAPI supported by the Java eclasses in ::gentoo. There was an ebuild whose upstream had been gone and whose SRC_URI was no longer accessible, and I managed to find a source JAR containing the package's source code on Maven Central and updated the ebuild to use it instead. At this point, the next package that needs to be fixed is dev-java/okio, which is a package containing Kotlin sources and thus should be built with a Kotlin compiler. Although my knowledge on Kotlin version compatibility is limited, I believe there can be situations where a package must be built by certain versions of the Kotlin compiler. This, plus fordfrog's interest in allowing users to keep multiple Kotlin versions in parallel, motivated me to think about how to implement support for multiple Kotlin compilers. On Gentoo, the obvious solution to this problem is to create an eselect module, but that would only allow coarse-grained system-wide control; chances are some packages require Kotlin 1.4 whereas others need Kotlin 1.5, thus the Kotlin version must be set independently for each individual package. For many other programming languages supported by Gentoo, including Lua, PHP, Python and Ruby, there are USE_EXPAND variables that can be used for this purpose, but such an approach would not work for Kotlin yet because USE_EXPAND is defined in Portage profiles, which I have no power to influence. As a workaround, I created a new kotlin-utils.eclass, added a variable that would allow ebuild developers to define either a single Kotlin version or an open interval of versions required by the package, and declared another variable for the order of preference on the accepted versions. The eclass can search for all Kotlin versions installed on the system and pick the best one according to the preference which satisfies any hard requirement. This would still compromise the end users' ability to select the Kotlin version used to build a package, but at least it could allow the ebuild developers to make a sensible choice for the users. Support for selecting a Kotlin version from ebuilds is provided by kotlin-utils.eclass, and the functionality to choose a Kotlin compiler for the user-space is shipped with the Kotlin eselect module. The module has a superset of features offered by the java-vm eselect module. It implements not only the notion of user and system compiler but also compiler preference settings for each Kotlin feature release version. This feature is provisioned for any alternative Kotlin compiler packages in the future, like dev-lang/kotlin with the "-bin" suffix dropped. For instance, if users have installed both dev-lang/kotlin:1.5 and dev-lang/kotlin-bin:1.5, then by using the Kotlin eselect module, they can control whether they want to use dev-lang/kotlin or dev-lang/kotlin-bin for Kotlin 1.5. It will be possible to use different Kotlin compiler packages for different feature releases too, so users can select dev-lang/kotlin:1.4 and dev-lang/kotlin-bin:1.5 at the same time. The version-specific Kotlin compiler preferences are recognized by both kotlin-utils.eclass and a set of versioned executables for Kotlin tools. Similar to commands like lua5.4, python3.9 and ruby26, versioned Kotlin commands like kotlin1.4 and kotlinc1.5 are installed with the Kotlin compiler packages and supported by the Kotlin eselect module. With these versioned commands, users can quickly switch to another Kotlin version without even invoking eselect. The versioned commands are not standard in the Kotlin compiler Zip archive distributed by the upstream (which is what other distributions' Kotlin packages usually depend on): they are exclusive on Gentoo, so I hope they will convince any GNU/Linux users who would like to install multiple Kotlin versions via the system package manager to consider using Gentoo. The new kotlin-utils.eclass, the Kotlin eselect module and some additional Kotlin eclasses are still being tested. They are working delightfully as of now, and I am trying to capture more issues and bugs before announcing and releasing them to more users. I sincerely hope that these utilities can form a robust framework for Kotlin packages and programs on Gentoo. Best regards, Leo [1]: https://github.com/Leo3418/eselect-kotlin --000000000000b04f1f05c8018c4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

Another week has just passed.=C2=A0 I have been gradually moving on to the = next part of my project where I would fix the ebuilds in the Spark overlay = that are no longer installable, most of which are caused by changes to ebui= lds in the Gentoo repository since last year's GSoC concluded.=C2=A0 At= the same time, a few additional utilities supporting Kotlin on Gentoo have= been created, including an eselect module for Kotlin [1] and some new Kotl= in eclasses.

Many ebuilds in the Spark overlay depend on packages in ::gentoo, but some = dependencies have been broken due to removal of old slots or even deletion = of packages that were really too old.=C2=A0 In the former case, the depende= ncy could be quickly fixed by updating the slot, although the dependee pack= age would require some integration tests with the dependency's new slot= .=C2=A0 In the latter case, I would restore the removed ebuild from the Git= history of ::gentoo and add it to the Spark overlay.=C2=A0 This is probabl= y not the best resolution, but as the number of packages in the Spark overl= ay may suggest, Apache Spark is a complicated program whose dependency grap= h spans hundreds of libraries, so recreating each ebuild removed from ::gen= too from scratch might take too much time.=C2=A0 However, the ebuilds were = not restored willy-nilly.=C2=A0 ebuilds that used EAPI 5 were ported to EAP= I 7, the latest EAPI supported by the Java eclasses in ::gentoo.=C2=A0 Ther= e was an ebuild whose upstream had been gone and whose SRC_URI was no longe= r accessible, and I managed to find a source JAR containing the package'= ;s source code on Maven Central and updated the ebuild to use it instead.
At this point, the next package that needs to be fixed is dev-java/okio, wh= ich is a package containing Kotlin sources and thus should be built with a = Kotlin compiler.=C2=A0 Although my knowledge on Kotlin version compatibilit= y is limited, I believe there can be situations where a package must be bui= lt by certain versions of the Kotlin compiler.=C2=A0 This, plus fordfrog= 9;s interest in allowing users to keep multiple Kotlin versions in parallel= , motivated me to think about how to implement support for multiple Kotlin = compilers.=C2=A0 On Gentoo, the obvious solution to this problem is to crea= te an eselect module, but that would only allow coarse-grained system-wide = control; chances are some packages require Kotlin 1.4 whereas others need K= otlin 1.5, thus the Kotlin version must be set independently for each indiv= idual package.=C2=A0 For many other programming languages supported by Gent= oo, including Lua, PHP, Python and Ruby, there are USE_EXPAND variables tha= t can be used for this purpose, but such an approach would not work for Kot= lin yet because USE_EXPAND is defined in Portage profiles, which I have no = power to influence.=C2=A0 As a workaround, I created a new kotlin-utils.ecl= ass, added a variable that would allow ebuild developers to define either a= single Kotlin version or an open interval of versions required by the pack= age, and declared another variable for the order of preference on the accep= ted versions.=C2=A0 The eclass can search for all Kotlin versions installed= on the system and pick the best one=C2=A0= according to the preference=C2=A0which satisfies any hard requirement.=C2=A0 This would still compromis= e the end users' ability to select the Kotlin version used to build a p= ackage, but at least it could allow the ebuild developers to make a sensibl= e choice for the users.

Support for selecting a Kotlin version from ebuilds is provided by kotlin-u= tils.eclass, and the functionality to choose a Kotlin compiler for the user= -space is shipped with the Kotlin eselect module.=C2=A0 The module has a su= perset of features offered by the java-vm eselect module.=C2=A0 It implemen= ts not only the notion of user and system compiler but also compiler prefer= ence settings for each Kotlin feature release version.=C2=A0 This feature i= s provisioned for any alternative Kotlin compiler packages in the future, l= ike dev-lang/kotlin with the "-bin" suffix dropped.=C2=A0 For ins= tance, if users have installed both dev-lang/kotlin:1.5 and dev-lang/kotlin= -bin:1.5, then by using the Kotlin eselect module, they can control whether= they want to use dev-lang/kotlin or dev-lang/kotlin-bin for Kotlin 1.5.=C2= =A0 It will be possible to use different Kotlin compiler packages for diffe= rent feature releases too, so users can select dev-lang/kotlin:1.4 and dev-= lang/kotlin-bin:1.5 at the same time.

The version-specific Kotlin compiler preferences are recognized by both kot= lin-utils.eclass and a set of versioned executables for Kotlin tools.=C2=A0= Similar to commands like lua5.4, python3.9 and ruby26, versioned Kotlin co= mmands like kotlin1.4 and kotlinc1.5 are installed with the Kotlin compiler= packages and supported by the Kotlin eselect module.=C2=A0 With these vers= ioned commands, users can quickly switch to another Kotlin version without = even invoking eselect.=C2=A0 The versioned commands are not standard in the= Kotlin compiler Zip archive distributed by the upstream (which is what oth= er distributions' Kotlin packages usually depend on): they are exclusiv= e on Gentoo, so I hope they will convince any GNU/Linux users who would lik= e to install multiple Kotlin versions via the system package manager to con= sider using Gentoo.

The new kotlin-utils.eclass, the Kotlin eselect module and some additional = Kotlin eclasses are still being tested.=C2=A0 They are working delightfully= as of now, and I am trying to capture more issues and bugs before announci= ng and releasing them to more users.=C2=A0 I sincerely hope that these util= ities can form a robust framework for Kotlin packages and programs on Gento= o.

Best regards,
Leo

[1]: https://github.com/Leo3418/eselect-kotlin
--000000000000b04f1f05c8018c4b--