Week 5 – Modernization of Portage
Hey everyone, this week was a fun and satisfying one. Let’s get into it.
I wanted to work on the dependency resolution system of portage. It is a scary codebase and so Sam suggested I start with bugs related to the dependency resolution system. We decided on bug 528836. The bug is relatively simple (though it took me relatively long time to understand). In gentoo, there are virtual packages. If multiple packages can provide the same functionality / library, then there is a virtual package that depends on either one of them. Any package needing that functionality / library can depend on the virtual package and not worry about the specifics. The problem in this bug is that a package has two dependencies (let’s say) and one depends on a package and the other depends on the corresponding virtual package. Now portage tries to emerge both sides of the virtual package, which leads to conflicts. Ideally, the ebuild maintainers should have made both dependencies depend on the virtual package rather than the actual, but nonetheless portage should have been able to figure it. The first task was to reproduce the bug in a gentoo system.
There were several hurdles along the way. The bug was very old (from 2014). It is not reproduceable in the current state of portage or the ebuild repository. Luckily, we got an old stage3 from Andrey, one of the mentors. Gentoo moved to git from CVS only recently and so, we had to graft in the historical gentoo repo into the current repo to restore it to an older state. The major hurdle is my inexperience / knowledge with ebuilds. Though I have been using gentoo for a few years, I never bothered to create ebuilds or study them. So when I had to look through the ebuilds to figure out what is going on, it was a bit overwhelming. Reading through pages and pages of man pages, PMS and gentoo wiki and with a lot of help from Sam, we were able to reproduce the bug.
Writing a test for the bug
Sam suggested that I write a test for portage that would expose this behaviour. It had it’s own hurdles, but finally we were able to do it. It is not integrated into portage, but it can be found here. I really want to thank Sam again for his patience towards me. I sometimes ask the silliest of things, but he explains them with a smile. I could never be more thankful.
The next step will be towards trying to fix the bug with portage or declare the ebuild to be invalid (which is reasonable). We will also work towards integrating the test into portage. Sam will have to decide on that. I will keep you posted whatever happens.
I also sent a pull request, removing some unreachable / legacy code. At the time of submitting the pull request, GitHub’s pypy37 (one of the targets portage is tested against) runner had some issues. The tests will be rerun and the commit will be merged into master soon.
The mid term evaluations are coming up. The next week will be towards getting ready for that, fixing the above bug and maybe a few more type annotations. I’ll see you all next week.