Hey everyone, this week was a fun and satisfying one. Let\u2019s get into it.<\/p>\n
I wanted to work on the dependency resolution system of portage. It is a scary codebase and so\u00a0 Sam suggested I start with bugs related to the dependency resolution system. We decided on bug \u00a0528836<\/a>. 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,\u00a0 then there is a virtual package that depends on either one of them. Any package needing\u00a0 that functionality \/ library can depend on the virtual package and not worry about the specifics. The\u00a0 problem in this bug is that a package has two dependencies (let\u2019s say) and one depends on a\u00a0 package and the other depends on the corresponding virtual package. Now portage tries to emerge\u00a0 both sides of the virtual package, which leads to conflicts. Ideally, the ebuild maintainers should\u00a0 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\u00a0 system.<\/p>\n There were several hurdles along the way. The bug was very old (from 2014). It is not\u00a0 reproduceable in the current state of portage or the ebuild repository. Luckily, we got an old stage3\u00a0 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\u00a0 hurdle is my inexperience \/ knowledge with ebuilds. Though I have been using gentoo for a few\u00a0 years, I never bothered to create ebuilds or study them. So when I had to look through the ebuilds\u00a0 to figure out what is going on, it was a bit overwhelming. Reading through pages and pages of man\u00a0 pages, PMS and gentoo wiki and with a lot of help from Sam, we were able to reproduce the bug.<\/p>\n Sam suggested that I write a test for portage that would expose this behaviour. It had it\u2019s own\u00a0 hurdles, but finally we were able to do it. It is not integrated into portage, but it can be found here<\/a>. I\u00a0 really want to thank Sam again for his patience towards me. I sometimes ask the silliest of things,\u00a0 but he explains them with a smile. I could never be more thankful.<\/p>\n The next step will be towards trying to fix the bug with portage or declare the ebuild to be invalid\u00a0 (which is reasonable). We will also work towards integrating the test into portage. Sam will have to\u00a0 decide on that. I will keep you posted whatever happens.<\/p>\n I also sent a pull request<\/a>, removing some unreachable \/ legacy code. At the time of submitting the\u00a0 pull request, GitHub\u2019s pypy37 (one of the targets portage is tested against) runner had some issues.\u00a0 The tests will be rerun and the commit will be merged into master soon.<\/p>\n The mid term evaluations are coming up. The next week will be towards getting ready for that,\u00a0 fixing the above bug and maybe a few more type annotations. I\u2019ll see you all next week.<\/p>\n","protected":false},"excerpt":{"rendered":" Week 5 – Modernization of Portage Hey everyone, this week was a fun and satisfying one. Let\u2019s get into it. Context I wanted to work on the dependency resolution system of portage. It is a scary codebase and so\u00a0 Sam … Continue reading Writing a test for the bug<\/h2>\n
Unreachable code<\/h2>\n
Next week<\/h2>\n