Retroactively fixing the world
There seems to be some serious confusion around the way directories are installed in Gentoo. In this post, I would like to shortly explain the differences between different methods of creating directories in ebuilds, and instruct how to handle the issues related to installing empty directories and volatile locations.
Continue reading “Empty directories, *into, dodir, keepdir and tmpfiles.d”
As part of the recent effort into forming a new copyright policy for Gentoo, a research into the historical status has been conducted. We’ve tried to establish all the key events regarding the topic, as well as the reasoning behind the existing policy. I would like to shortly note the history based on the evidence discovered by Robin H. Johnson, Ulrich Müller and myself.
Over the time, a number of developers have had problems following the Gentoo OpenPGP key policy (GLEP 63. In particular, the key expiration requirements have resulted in many developers wanting to replace their key unnecessarily. I’ve been asked to write some instructions on managing your OpenPGP key, and I’ve decided to go for a full blog post with some less-known tips. I won’t be getting into detailed explanations how to use GnuPG though — you may still need to read the documentation after all.
While the work on new Gentoo copyright policy is still in progress, I think it would be reasonable to write a short article on copyright in general, for the benefit of Gentoo developers and contributors (proxied maintainers, in particular). There are some common misconceptions regarding copyright, and I would like to specifically focus on correcting them. Hopefully, this will reduce the risk of users submitting ebuilds and other files in violation of copyrights of other parties.
Back when EAPI 6 was approved and ready for deployment, I have written a blog post entitled the Ultimate Guide to EAPI 6. Now that EAPI 7 is ready, it is time to publish a similar guide to it.
Of all EAPIs approved so far, EAPI 7 brings the largest number of changes. It follows the path established by EAPI 6. It focuses on integrating features that are either commonly used or that can not be properly implemented in eclasses, and removing those that are either deemed unnecessary or too complex to support. However, the circumstances of its creation are entirely different.
EAPI 6 was more like a minor release. It was formed around the time when Portage development has been practically stalled. It aimed to collect some old requests into an EAPI that would be easy to implement by people with little knowledge of Portage codebase. Therefore, the majority of features oscillated around bash parts of the package manager.
EAPI 7 is closer to a proper major release. It included some explicit planning ahead of specification, and the specification has been mostly completed even before the implementation work started. We did not initially skip features that were hard to implement, even though the hardest of them were eventually postponed.
I will attempt to explain all the changes in EAPI 7 in this guide, including the rationale and ebuild code examples.