{"id":496,"date":"2023-06-25T20:41:14","date_gmt":"2023-06-25T20:41:14","guid":{"rendered":"https:\/\/blogs.gentoo.org\/gsoc\/?p=496"},"modified":"2023-06-25T20:41:14","modified_gmt":"2023-06-25T20:41:14","slug":"week-4-report-automated-gentoo-system-updater","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/gsoc\/2023\/06\/25\/week-4-report-automated-gentoo-system-updater\/","title":{"rendered":"Week 4 Report, Automated Gentoo System Updater"},"content":{"rendered":"

This article is a summary of all the changes made on\u00a0Automated Gentoo System Updater<\/a>\u00a0project during\u00a0week 4<\/strong>\u00a0of GSoC.<\/p>\n

Project is hosted on\u00a0Github<\/a>.<\/p>\n

Progress on Week 4<\/h3>\n

Started the week by discovering that my updates to ebuild were\u00a0not accepted<\/a>\u00a0in the GURU overlay. The issue arose due to a misuse of USE flags feature in the ebuild. Maintainers of GURU (big thanks to\u00a0antecrescent<\/strong>!) pointed out my mistake and explained how to fix it, which I did by submitting 2 more commits (\u00a0commit1<\/a>\u00a0and\u00a0commit2<\/a>).<\/p>\n

Then I proceeded to write an introductory blog post. It can currently be read in\u00a0Gentoo GSoC blog<\/a>. I\u2019ve delayed posting about it on forums because I was waiting for the newest ebuild version to be merged to the main branch in GURU overlay (and because I was a bit anxious to be honest \ud83d\ude30). But in the end I decided to stop waiting, and just mentioned in the blog post that gentoo_update<\/em>\u00a0can be also installed via pip.
\nForum post can be found\u00a0here<\/a>.<\/p>\n

Updater also received some improvements overall. I found errors in\u00a0–args<\/em>\u00a0flag (used for passing custom parameters to\u00a0emerge<\/em>), in some cases it was not reading all parameters correctly. To fix the problem I changed the input type, now it receives a string of space separated parameters instead of a list, for example\u00a0“quiet-build=y color=y”<\/em>, and the problem was fixed.<\/p>\n

Also the packaging with Python\u2019s setuptools was improved, now there are no warnings during wheel building.<\/p>\n

Finally, I started working on the parser. Right now it can only split the output to different categories.<\/p>\n

Overall, the week was not a very productive one, but many bugs and imperfections were discovered and fixed which is great because I can now focus on the parser!<\/p>\n

Challenges<\/h3>\n

It was a bit challenging to understand the reason why USE flags were not a good solutions in my case, but after I got it it suddenly became obvious \ud83e\udd13<\/p>\n

I used USE flags to install optional dependencies for the updater. However, USE flags are typically meant to guide Portage in the program\u2019s build and compilation processes, and in this case USE flags don\u2019t change the outcome of how the program is built. If these flags are ever removed, it would trigger an unnecessary recompilation of the updater. The proper management of optional dependencies, as\u00a0recommended<\/a>\u00a0by antecrescent, involves using the\u00a0optfeature eclass<\/a>. This approach provides users with dependency information and prompts them to consider installing dependencies by themselves.<\/p>\n

Then it was a bit tricky to get rid of warnings from setuptools (it feels like I\u2019m struggling with setuptools every week \ud83d\ude14). Warning were saying that\u00a0updater.sh<\/em>\u00a0and even\u00a0tests<\/em>\u00a0directories were treated as Python packages, which was a problem because\u00a0update.sh<\/em>\u00a0is a Bash script, and\u00a0tests<\/em>\u00a0contains scripts and Docker compose file used for tests, and both of them were not meant to be a package. I found a solution in Gentoo\u2019s\u00a0Python Guide<\/a>\u00a0which suggested a proper way to exclude the packages to avoid issues with Portage.<\/p>\n

\n

Plans for Week 5<\/h3>\n

Mostly I plan to work on the parser the whole week. Here is the checklist from last week:<\/p>\n