As this year’s GSoC has come and gone, it is time to compile a retrospective of all the work I have done for my GSoC project. In a nutshell, the bulk of my project was executed as I had planned in my original project proposal; some additional deliverables and enhancements not outlined in the original plan were made, while a few planned and relatively trivial deliverables were cut due to time constraints. …
Common package managers implement the concept of software repositories to allow the set of packages installable from the package manager to be expanded. On Fedora, there is RPM Fusion and Copr repositories created and maintained by users. Arch Linux users are fond of the AUR, the canonical repository for user-submitted packages. On Gentoo, there is GURU, which is kind of like Gentoo’s equivalent of AUR, but it is just the tip of the iceberg of packages that are not in the official Gentoo ebuild repository (::gentoo). There are various testing overlays maintained by projects and development teams of Gentoo and repositories for out-of-tree ebuilds, like ::gnome, ::java, and ::science, let alone plenty of user personal overlays, like the Spark overlay I have been working on for example. …
Dependency is a concept that appears often in software engineering. In the previous article for my GSoC project, I discussed build systems and package managers, both of which apply the concept of dependencies. A build system usually allows programmers to define different tasks in building a project and let each of them depend on other tasks, hence dependency relationships are established. A package manager supports declaration of package dependency relationships, or else it is not a good package manager. This article focuses on the latter, which is dependency relationships among packages. …
An initial and successful attempt to create source-based Kotlin packages on Gentoo
Since the last blog post regarding my GSoC project was posted, I moved on to the next part of the project: improvements on the Kotlin ebuilds in the Spark overlay created during last year’s GSoC, namely dev-java/kotlin-common-bin and dev-lang/kotlin-bin. As shown by the -bin suffix in the packages’ names, these are packages that simply install the Kotlin library and compiler binary JARs pre-built by the upstream instead of build those artifacts from source like how the vast majority of Gentoo packages do and how Gentoo’s guidelines propose. At first, I thought it would be hard to build Kotlin from source on Gentoo with Portage, so I did not make any plan to create separate versions of those packages without the -bin suffix. Coincidentally, I discovered a possible way to work around Portage’s limitations that would prevent Kotlin from being built from source, so I immediately started to conduct experiments on building Kotlin libraries from source within Portage. The experiment results were promising, therefore I decided to spend some time working on this and eventually created ebuilds that can build Kotlin core libraries from source with a success. In this post, I will cover possible challenges in building a project like the Kotlin programming language on Gentoo, how my method of building it on Gentoo was accidentally discovered, and how the final ebuilds were produced. …
Another mysterious disappearance of me from my personal website has happened after the previous one in last November. The reason is the same: I had been quite busy. But unlike last time, I do not think that the things which kept me busy in the past month were futile. I spent significant amount of time helping students in a software engineering course for which I was a teaching assistant, and assisting others is always a meaningful activity in my opinion, regardless of the type of assistance being offered, the context, the recipient of the assistance, or the form. …