1 |
Hi folks, |
2 |
|
3 |
The past week was largely a week of stabilization. First and |
4 |
foremost, I tried to use the Kotlin eclasses I had worked on about a |
5 |
week ago to retrofit existing ebuilds for Kotlin packages including |
6 |
okhttp, okio and reactor-core, all of which were successful. After |
7 |
tinkering with those eclasses, I believed they were ready for creation |
8 |
of more Kotlin packages on Gentoo. eselect-kotlin was also stabilized |
9 |
a few days later with an initial v0.1.0 release and a specification |
10 |
for any Kotlin compiler packages on Gentoo that are intended to be |
11 |
recognized by the eselect module [1]. Then, I continued to fix broken |
12 |
ebuilds in the Spark overlay and finally reached a state where all |
13 |
packages can be installed with the default USE flag settings, and the |
14 |
changes have been merged into Zongyu's main repository created last |
15 |
year. During this process, I also helped resolve a bug in the |
16 |
dev-java/zstd-jni package (#776910) when it was being pulled as a |
17 |
dependency of packages in the Spark overlay and bump dev-java/jansi in |
18 |
::gentoo to 1.13 after fixing an ebuild in the Spark overlay for the |
19 |
same version of the package. |
20 |
|
21 |
Before I started to revamp existing ebuild in the Spark overlay, there |
22 |
were about 60 out of 500 packages that could not be built from source |
23 |
and thus would require USE="binary" to be explicitly enabled for them |
24 |
by the users. This week, I went through each of them one by one in |
25 |
the hope to make them installable without the 'binary' USE flag. The |
26 |
most common reason that they could not be built from source was issues |
27 |
within dependencies, and one of the following resolution was applied |
28 |
to each ebuild depending on the actual situation: |
29 |
|
30 |
- A dependency's version was incorrect, and the correct version was |
31 |
available in either ::gentoo or the Spark overlay. If the correct |
32 |
version was in a different slot, then the slot would be changed in the |
33 |
problematic ebuild. Otherwise, a new slot would be created for the |
34 |
correct version so that the problematic ebuild could use the version |
35 |
without affecting other ebuilds. |
36 |
|
37 |
- A dependency's version was incorrect, and the correct version is too |
38 |
old. This often happened to packages requiring Guava. If an ebuild |
39 |
in the Spark overlay would need Guava, it usually would depend on |
40 |
Guava 29.0; but, the correct Guava version needed to build some of the |
41 |
packages could be as old as 18.0. In this case, the reason the ebuild |
42 |
could not be compiled from source was that some APIs in Guava had been |
43 |
removed. Fortunately, for every removed API, Google would state its |
44 |
replacement API(s) in Guava's documentation, so this kind of issue |
45 |
could be resolved by patching the problematic ebuild's source files to |
46 |
switch to the replacement APIs. |
47 |
|
48 |
- A package that existed in either ::gentoo or the Spark overlay was |
49 |
missing in the build-time classpath. In this case, the package would |
50 |
be added to the problematic ebuild as a dependency. |
51 |
|
52 |
- A package that did not exist was required for building, and an |
53 |
ebuild for the package could be easily created with java-ebuilder or |
54 |
by hand. The new ebuild would be added to the Spark overlay, and the |
55 |
problematic ebuild would depend on it. |
56 |
|
57 |
- A package that did not exist was required, and it was hard to create |
58 |
an ebuild for it; or, the build failure was caused by an issue not |
59 |
related to dependencies and could not be trivially fixed. To save |
60 |
time for the remaining final parts of my GSoC project, I just simply |
61 |
added IUSE="+binary" to the ebuild to enable the USE flag by default |
62 |
with a comment describing the obstacles to compile the package from |
63 |
source. |
64 |
|
65 |
My new blog post for this week is now available [2]. The topic for |
66 |
this post is the ebuild testing infrastructure I created and have been |
67 |
using to verify the working status of ebuilds in the Spark overlay. |
68 |
An interesting fact for the testing framework is that I used it to |
69 |
test my fix for the zstd-jni bug and the new jansi-1.13 ebuild too, so |
70 |
it is not only suitable for testing small ebuild repositories but |
71 |
probably can be used to test a subset of ebuilds in ::gentoo as well. |
72 |
|
73 |
Thanks for reading, |
74 |
Leo |
75 |
|
76 |
[1]: https://github.com/Leo3418/eselect-kotlin/blob/v0.1.0/README.md#gentoo-kotlin-compiler-package-specification |
77 |
[2]: https://leo3418.github.io/2021/08/01/ebuild-repos-testing-solution.html |