Now that EAPI\u00a06 is Council-approved and\u00a0pretty close to being deployed, I think it’s about time to write up a\u00a0not-so-short guide to it. It’s especially important that EAPI\u00a06 is a\u00a0bit different from the\u00a0previous EAPIs. It was not only seen as an\u00a0opportunity to add new features but also to tidy things up a\u00a0bit and\u00a0improve strictness.<\/p>\n
If you look into the\u00a0PMS, you’d see that we’d not only added completely new stuff but also ported a\u00a0few common eclass functions, in a\u00a0little cleaner form, and\u00a0new useful phase functions. Furthermore, we used EAPI\u00a06 as an\u00a0opportunity to finally increase strictness of\u00a0Portage in\u00a0regard to\u00a0PMS, and\u00a0ban some long-unwanted eclasses.<\/p>\n
Therefore, I’d like to ask you \u2014 please don’t go hooray-enabling EAPI\u00a06 support in\u00a0your ebuilds and\u00a0eclasses. Take a\u00a0while to think, and\u00a0do things right. Please think of EAPI\u00a06 as a\u00a0lifetime opportunity of\u00a0improving your eclass APIs, as we improved the\u00a0API provided by\u00a0Package Managers.<\/p>\n
Now, time for a\u00a0little summary of\u00a0changes, their implications and\u00a0a\u00a0bit of\u00a0rationale.<\/p>\n
<\/p>\n
The\u00a0first important change in\u00a0EAPI 6 is the\u00a0upgrade to bash-4.2 (the\u00a0earlier EAPIs required bash-3.2). At a\u00a0first glance, it just brings a\u00a0few nice quirks like cleaner fd magic (used by multiprocessing.eclass), case conversion for variables and\u00a0associative arrays. However, aside to that bash compatibility setting is forced \u2014 that could hopefully prevent existing code from breaking in\u00a0future bash versions.<\/p>\n
What does this solve, you ask? For example, it solves the\u00a0tilde substitution issue:<\/p>\n
PV=\"0_beta1\"\r\nMY_PV=\"${PV\/_\/~}\"<\/code><\/pre>\nThe\u00a0above snippet gives the\u00a0expected result only when executed with bash-4.2 and\u00a0lower. However, starting with bash-4.3 it performs tilde expansion on right-hand argument of the\u00a0pattern substitution and\u00a0puts your home directory in\u00a0there. You can disable that via backslash-escaping the\u00a0argument \u2014 but then it puts an\u00a0extra backslash in\u00a0older bash versions! How frustrating\u2026<\/p>\n
Now, if we have BASH_COMPAT<\/code> fixed by the\u00a0PM at 4.2, this discrepancy is no longer an\u00a0issue. Because all supported versions of\u00a0bash will force the\u00a0old behavior, you can write the\u00a0code without any conditionals, workarounds or worrying that it will suddenly break sometime in the\u00a0future.<\/p>\nfailglob in\u00a0global scope<\/h2>\n
The\u00a0second change to ebuild syntax is that filename expansion is now an\u00a0explicit error in\u00a0global scope. While this may sound scary at first, it wasn’t ever really supported. Note that this doesn’t affect phase functions, just the\u00a0code executed when sourcing the\u00a0ebuild. This is mostly targeted towards snippets like the\u00a0following:<\/p>\n
inherit python-r1\r\n\r\nRDEPEND=\"$(python_gen_cond_dep 'dev-python\/foo[${PYTHON_USEDEP}]' python2*)\"<\/code><\/pre>\nDo you see the\u00a0problem here? python2*<\/code> lacks quoting. This usually doesn’t cause any issues but if you happened to be in a\u00a0directory with pythonFOOBAR<\/code> file while sourcing the\u00a0ebuild, it would suddenly pick it up and\u00a0return pretty unexpected results. As a\u00a0solution, an\u00a0EAPI=6 ebuild would instantly abort here and\u00a0require you to quote the\u00a0pattern.<\/p>\nLC_COLLATE and LC_CTYPE settings<\/h2>\n
The\u00a0description for locale settings may seem a\u00a0little blurry but that’s for a\u00a0reason. The\u00a0original idea was that the\u00a0Package Manager would export (pretty much like Paludis does):<\/p>\n
LC_COLLATE=C\r\nLC_CTYPE=C<\/code><\/pre>\nto enforce stable sorting and\u00a0case conversions. Without the\u00a0former, some locales could cause results of\u00a0globs such as patch files to apply in\u00a0different order. Without the\u00a0latter, some locales could give unexpected results of case changes. In particular, the\u00a0Turkish tr_TR.UTF-8<\/code> locale is only too happy to map lowercase \u2018i\u2019 to uppercase \u2018\u0130\u2019 (yep, it has a\u00a0dot above!)<\/p>\nSo why is it worded this muddy? Because of our lovely Python and\u00a0the\u00a0lot of\u00a0high quality scripts that are only too happy to interpret read files in the\u00a0charset corresponding to the\u00a0current locale, and\u00a0therefore bail out hard when they don’t conform to the\u00a0ASCII charset implied by the\u00a0C<\/code> locale.<\/p>\nSo instead of\u00a0C<\/code>, we need a\u00a0C.UTF-8<\/code> which hasn’t made its way into glibc for\u2026 how long exactly? Not to mention the\u00a0portability. Therefore, we just request a\u00a0seemingly sane locale, and\u00a0hope we can work something out. In\u00a0implementation, the\u00a0Package Manager will most likely set LC_COLLATE=C<\/code> directly and\u00a0complain to the\u00a0user if\u00a0his LC_CTYPE<\/code> does not conform.<\/p>\nNevertheless, in\u00a0EAPI\u00a06 you should be able to safely remove your local LC_COLLATE<\/code> and\u00a0LC_CTYPE<\/code> redefinitions, and\u00a0hopefully also most of\u00a0those excessive LC_ALL<\/code> settings.<\/p>\neapply, eapply_user and\u00a0src_prepare()<\/h2>\n
This is probably the\u00a0most controversial feature of the\u00a0new EAPI. Those functions are intended as reasonably simple and\u00a0predictable replacements for the\u00a0commonly used eutils.eclass beasts, with new default src_prepare()<\/code> to finish off the\u00a0long-deprecated base.eclass.<\/p>\neapply<\/code> has a\u00a0few substantial differences from epatch<\/code>. However, I hope that people will nevertheless decide to abandon the\u00a0latter, and\u00a0use the\u00a0new function, effectively also reducing the\u00a0use of\u00a0eutils.eclass. The\u00a0differences are:<\/p>\n\n- No
-p*<\/code> guessing. Instead, it defaults to -p1<\/code> and\u00a0lets you override it. Now patches can apply predictably.<\/li>\n- No magical configuration variables. All options are passed as\u00a0parameters, followed by files. If options need to take separate arguments,
--<\/code> is provided to separate options from files.<\/li>\n- No compression support. There’s
unpack<\/code> that usually does that for you, you know, and\u00a0patches in\u00a0${FILESDIR}<\/code> are never compressed.<\/li>\n- Simple directory handling. It just applies all
*.diff<\/code> and *.patch<\/code> files from a\u00a0directory. No custom suffixes, no exclusions.<\/li>\n<\/ul>\nWhile this may sound like a\u00a0lot was lost, the\u00a0function is still quite big and\u00a0even twice as\u00a0useful. Most importantly, all patches now apply (or fail) pretty predictably, and\u00a0if they do fail, you get a\u00a0clear output.<\/p>\n
eapply_user<\/code> provides user patch support on top of\u00a0eapply<\/code>. However, since user patches are a\u00a0matter of\u00a0configuration, the\u00a0PMS really leaves the\u00a0details to the\u00a0Package Manager, and doesn’t even prohibit it from extending patching beyond eapply<\/code>. eapply_user<\/code> is considered obligatory, and\u00a0can be safely called more than once (applying patches only the\u00a0first time) to make eclass writing easier.<\/p>\nBoth function are used in\u00a0the\u00a0default src_prepare()<\/code> implementation which was inspired by the\u00a0common implementations shared between multiple eclasses. In\u00a0particular, it applies patches from the\u00a0PATCHES<\/code> variable (array strongly preferred due to ${FILESDIR}<\/code>) and\u00a0then user patches. Please note that in\u00a0some cases, it would be advised to remove src_prepare()<\/code> from your eclass altogether rather than calling the\u00a0default from it.<\/p>\neinstalldocs and\u00a0src_install()<\/h2>\n
This one’s much simpler and\u00a0accepted in\u00a0full agreement. It combines two categories of\u00a0requests created against the\u00a0documentation install code introduced in\u00a0EAPI\u00a04. Firstly, it splits the\u00a0code off default_src_install()<\/code> so that it can be reused without implicitly calling emake install<\/code>. Secondly, it solves a\u00a0number of\u00a0problems with the\u00a0original implementation.<\/p>\nSo what’s the\u00a0story here? EAPI\u00a04 introduced a\u00a0very nice src_install()<\/code> phase which was able to install a\u00a0few default documentation pieces automatically. That was quite liked, except that it was tightly bound with the\u00a0default emake install<\/code> call. As a\u00a0result, a\u00a0number of\u00a0eclasses ended up (still) redefining it, with the\u00a0most noticeable example of\u00a0base.eclass having a\u00a0split phase function for it. But since the\u00a0eclass was long deprecated already, other eclasses had to copy the\u00a0code rather than reuse it.<\/p>\nThe\u00a0idea of having a\u00a0split function arose early during EAPI\u00a06 work. While writing a\u00a0new function, the\u00a0issues and\u00a0requests against the\u00a0current default were collected and\u00a0considered. Finally, the\u00a0new function was given to early Council approval, and\u00a0committed to eutils.eclass as\u00a0a\u00a0backport of\u00a0the\u00a0future EAPI\u00a06 function. And as you can see now, it lands in\u00a0EAPI\u00a06 in\u00a0exactly the\u00a0same form, replacing the\u00a0eutils implementation.<\/p>\n
As a\u00a0reminder, the\u00a0changes from the\u00a0original EAPI\u00a04 implementation are:<\/p>\n
\n- empty
DOCS<\/code> variable disables installing documentation completely. Previously, it was undefined behavior (usually a\u00a0dodoc<\/code> usage error).<\/li>\n- The\u00a0
DOCS<\/code> variable can name directories as well as files.<\/li>\n- A\u00a0
HTML_DOCS<\/code> variable has been added. It installs the\u00a0listed files and\/or directories (using dodoc<\/code>, not deprecated dohtml<\/code>!) into the\u00a0html\/<\/code> subdirectory of docdir.<\/li>\n<\/ul>\nAs a\u00a0result, the\u00a0default src_install()<\/code> implementation differs by the\u00a0documentation install changes listed above. If you were overriding this phase just to get einstalldocs<\/code> into it, you can remove it. If you were using einstalldocs<\/code> from eutils.eclass, you do not have to inherit it anymore. And if you were inlining your own documentation install code, it is a\u00a0good idea to replace it with standard one in\u00a0EAPI\u00a06.<\/p>\nget_libdir and econf changes<\/h2>\n
The\u00a0next major target for EAPI\u00a06 changes was the\u00a0econf<\/code> function, commonly used in\u00a0src_configure()<\/code>. Here, two goals were achieved. Firstly, a\u00a0get_libdir<\/code> function inspired by multilib.eclass was added. Secondly, --docdir<\/code> and\u00a0--htmldir<\/code> parameters are now passed to configure scripts.<\/p>\nWhy would get_libdir<\/code> be related to econf<\/code> at all? Well, except for the\u00a0fact that it’s often used in\u00a0configure script arguments, it pretty much shares the\u00a0logic used to figure out libdir. So we’re not just moving a\u00a0commonly used eclass function to the\u00a0EAPI \u2014 we’re splitting the\u00a0libdir determination logic off econf<\/code>, and\u00a0sharing it with ebuilds.<\/p>\nAs for the\u00a0two new parameters \u2014 --docdir<\/code> and\u00a0--htmldir<\/code> \u2014 I don’t think they really need any comment here.<\/p>\nin_iuse<\/h2>\n
This one’s very controversial as\u00a0well, and\u00a0I’d personally prefer not having to introduce it at\u00a0all. However, without it the\u00a0developers would still resort to ugly hacks, so better to have a\u00a0safe alternative. So, what’s the\u00a0background?<\/p>\n
Some developers found it quite convenient to do some conditionals in\u00a0eclasses based on what ends up in\u00a0IUSE<\/code>. For example, if\u00a0the\u00a0ebuild has IUSE=static-libs<\/code>, we magically enable code controlling static library build and\u00a0install. Except for being ugly, this design had two major issues. Firstly, the\u00a0code checking that was inconsistent and\u00a0often buggy \u2014 some eclasses handled +static-libs<\/code>, some didn’t. Secondly, the\u00a0specification never mandated IUSE<\/code> having any sane value throughout phase functions. So the\u00a0results could have been quite surprising.<\/p>\nEAPI\u00a06 solves both of those issues by\u00a0providing a\u00a0standard in_iuse<\/code> function. All uses implementation-defined magic to check whether the\u00a0specified flag is listed in\u00a0the\u00a0IUSE_EFFECTIVE<\/code> conceptual variable. This includes not only flags set by\u00a0ebuilds and\u00a0eclasses but also implicitly added by\u00a0profiles \u2014 in\u00a0other words, any flag that is legal to the\u00a0use<\/code> function call.<\/p>\nI should note that in_iuse<\/code> is legal only in\u00a0phase functions \u2014 it is disallowed in\u00a0global scope (i.e. while IUSE<\/code> is still subject to changes). Nevertheless, I would heartily recommend avoiding it and\u00a0using explicit conditional variables instead.<\/p>\nnonfatal die<\/h2>\n
Did you happen to dislike how some eclass-defined helpers could not be nonfatal<\/code> properly? That’s no longer the\u00a0case with EAPI\u00a06. The\u00a0die<\/code> function has gained a\u00a0simple -n<\/code> option which makes it respect nonfatal<\/code>, and\u00a0therefore be a\u00a0no-op when it is in\u00a0effect.<\/p>\nIn\u00a0other words, you can write helpers like the\u00a0following:<\/p>\n
efoo() {\r\n\t#...\r\n\tfoo || die -n \"foo failed\" || return ${?}\r\n\t#...\r\n}<\/code><\/pre>\nwhere die<\/code> would simply return false and\u00a0continue execution if\u00a0nonfatal<\/code> is in\u00a0effect. Please remember that \u2018nonfatal die\u2019 does not return<\/code> from the function implicitly. If you need to do so, you need to explicitly call return<\/code> like in the\u00a0above snippet.<\/p>\nunpack changes<\/h2>\n
Now we’re past the\u00a0most interesting changes. For completeness, there were few small requests accepted for the\u00a0unpack<\/code> function:<\/p>\n\n- Absolute and\u00a0non-prefixed relative paths can be used now. The\u00a0path handling is still a\u00a0little creepy since pure filename (i.e. without a\u00a0single slash) implicitly references
${DISTDIR}<\/code> but anything with a\u00a0slash is treated as a\u00a0regular path.<\/li>\n.txz<\/code> suffix is interpreted equivalently to .tar.xz<\/code>. Previously, only the\u00a0long form was accepted.<\/li>\n- Suffix matching is case-insensitive now. Which means that
.ZIP<\/code> works as\u00a0well as\u00a0.zip<\/code>. Hooray, we can now handle 8.3 filenames cleanly!<\/li>\n<\/ul>\neinstall banned, dohtml deprecated<\/h2>\n
Aside to new features, there are two important removals to be noted. The\u00a0long-discouraged einstall<\/code> function has been finally banned, and\u00a0the\u00a0dohtml<\/code> function has been deprecated with the\u00a0goal of\u00a0removing it in\u00a0EAPI\u00a07.<\/p>\nThe\u00a0einstall<\/code> command was intended as a\u00a0cheap work-around for build systems that did not support DESTDIR=<\/code> argument to emake install<\/code>. Instead, it redefined a\u00a0number of direct install paths (such as bindir=<\/code>), passing the\u00a0staging area path and\u00a0target directory combined. Sadly, it has often been cause of\u00a0confusion for new developers who have seen it as\u00a0the\u00a0standard install command (in\u00a0line with econf<\/code>, emake<\/code>\u2026).<\/p>\nOver a\u00a0year ago, I’ve started tracking uses of\u00a0einstall<\/code> on\u00a0behalf of\u00a0QA, and\u00a0noticed that most of\u00a0the\u00a0uses were completely unnecessary, either because the\u00a0build system in\u00a0question handled DESTDIR=<\/code> correctly, or had a\u00a0custom variable serving the\u00a0same purpose. Furthermore, the\u00a0function used parameter names matching autoconf while it was intended to deal with custom build systems which may require other variables. Therefore, it was decided that it is better to ban the\u00a0command and\u00a0inline the\u00a0relevant make parameters whenever really unavoidable.<\/p>\nThe\u00a0dohtml<\/code> function has been the\u00a0official way of\u00a0installing HTML documentation for quite a\u00a0long time. No other command defined by\u00a0PMS had as\u00a0many options. Confusingly to some developers, it provided implicit filtering by file suffixes, with additional options to add additional suffixes, replace suffix list, filter by filename, exclude directories and\u00a0directly alter install path. Moreover, there was yet another enhancement request asking for new suffixes in\u00a0the\u00a0default filter.<\/p>\nThe\u00a0Council has agreed with us that the\u00a0function is overcomplex and\u00a0confusing, and\u00a0will be an\u00a0object of never-ending requests and\u00a0updates. Most of Gentoo developers have seen it as a\u00a0way of installing files in\u00a0the\u00a0html\/<\/code> subdirectory of\u00a0docdir while it did so much more \u2014 and\u00a0potentially confused them by excluding some files. It also resulted in\u00a0absurd situations like people moving gtk-doc files out of the\u00a0standard location used by\u00a0gtk-doc just to match the\u00a0\u2018standard\u2019 established by\u00a0the\u00a0function.<\/p>\ndohtml<\/code> is officially deprecated since EAPI\u00a06, and\u00a0is expected to be\u00a0banned in\u00a0EAPI\u00a07. The\u00a0suggested replacement is dodoc<\/code> which is much simpler, faster and\u00a0in\u00a0many cases will work the\u00a0same (or even better, by restoring the\u00a0files that were mistakenly missed by\u00a0dohtml<\/code>). It is possible that the\u00a0current dohtml<\/code> will eventually be moved to an\u00a0eclass for the\u00a0ebuilds that require filtering, yet the\u00a0fate of\u00a0this idea is unclear yet.<\/p>\nTo help with the\u00a0migration, Portage provides the following quirk (for make.conf<\/code> or environment):<\/p>\nPORTAGE_DOHTML_WARN_ON_SKIPPED_FILES=yes<\/code><\/pre>\nWhen run with this, each dohtml<\/code> invocation will verbosely list all files that were skipped through filtering. A\u00a0null output indicates that dohtml<\/code> can be safely replaced by\u00a0dodoc<\/code>.<\/p>\nGlobal-scope helpers banned in\u00a0Portage<\/h2>\n
EAPI\u00a06 brings not only the\u00a0spec changes but also new strictness to\u00a0Portage. In\u00a0particular, almost all helper functions are now banned in\u00a0global scope, as they are banned by\u00a0PMS and\u00a0other package managers. What does this imply? Most importantly, toolchain’s use of USE=multislot<\/code> is now officially banned and\u00a0will no longer work in\u00a0EAPI\u00a06.<\/p>\nEclasses banned in EAPI 6<\/h2>\n
Finally, the\u00a0changes brought by EAPI\u00a06 will likely result in\u00a0a\u00a0number of API changes in\u00a0multiple eclasses. Moreover, some of\u00a0the\u00a0existing eclasses will become completely unnecessary and\u00a0will be banned.<\/p>\n
The\u00a0most important example here is the\u00a0base.eclass which was semi-officially deprecated for a\u00a0long time. In EAPI\u00a06, it is fully replaced by\u00a0default phase functions and\u00a0must not be used. Similarly, I’ve decided to discontinue and\u00a0ban autotools-utils.eclass and\u00a0autotools-multilib.eclass, the\u00a0former serving a\u00a0similar purpose as\u00a0base.eclass did in\u00a0the past and\u00a0the\u00a0latter being just a\u00a0wrapper atop multilib-minimal.eclass.<\/p>\n
Aside to that, I’ve banned a\u00a0number of eclasses that are deprecated currently, to avoid their use being carried on to the\u00a0next EAPI.<\/p>\n
Summary<\/h2>\n
To summarize all the\u00a0changes in\u00a0EAPI\u00a06, let me assemble a\u00a0check list of tasks that need to be done when updating ebuilds to EAPI\u00a06:<\/p>\n
\n- You can update your bash code to use bash-4.2 features, and\u00a0remove unnecessary conditionals for future-incompatible behavior. It is unlikely that you have any.<\/li>\n
- Ensure that all patterns that are supposed to be passed as-is to functions are quoted.<\/li>\n
- Remove unnecessary
LC_COLLATE<\/code> and\u00a0LC_CTYPE<\/code> if they only reset it to the\u00a0C<\/code> (or\u00a0POSIX<\/code>) locale.<\/li>\n- If you are using
epatch<\/code>, try hard to replace it with eapply<\/code>. You may need to pass an\u00a0explicit -p<\/code> value.<\/li>\n- If you are using
epatch_user<\/code>, you have to replace it with eapply_user<\/code>. If you are not and you define src_prepare()<\/code>, you have to add it there.<\/li>\n- If you are left with
src_prepare()<\/code> that looks pretty much like the\u00a0default one, drop it. It is also a\u00a0good idea to remove unnecessary src_prepare()<\/code> definitions from eclasses.<\/li>\n- If you are using
einstalldocs<\/code>, this function is now part of\u00a0EAPI. Don’t count it as a\u00a0reason to\u00a0inherit eutils.eclass. If you are using a\u00a0similar inline code, it’s about time you switch to einstalldocs<\/code>.<\/li>\n- If you are using
in_iuse<\/code>, this function is now part of\u00a0EAPI and\u00a0even really legal. Don’t count it as a\u00a0reason to\u00a0inherit eutils.eclass. In\u00a0fact, hurry to switch to EAPI\u00a06 to get a\u00a0predictable behavior!<\/li>\n- Check if you are still using anything from eutils.eclass. If you are not, remove the\u00a0inherit and\u00a0save a\u00a0few cycles.<\/li>\n
- If you are using
get_libdir<\/code>, this function is now part of\u00a0EAPI. Don’t count it as a\u00a0reason to\u00a0inherit multilib.eclass. If you are not using anything else from multilib.eclass, remove the\u00a0inherit.<\/li>\n- If you are passing standard
--docdir<\/code> and\/or --htmldir<\/code> to econf<\/code>, you can remove them. EAPI\u00a06 does that for you.<\/li>\n- If you are defining ebuild helpers that should respect
nonfatal<\/code>, you should update appropriate die<\/code> to use die -n || return<\/code>. However, please note that it’s usually a\u00a0good idea to use regular die<\/code> on usage errors, and respect nonfatal only for external errors.<\/li>\n- If you are using hacks to support
.txz<\/code>, uppercase archive suffixes like .ZIP<\/code> or extracting files by\u00a0absolute or\u00a0relative paths, you can remove them and\u00a0use new unpack<\/code> features.<\/li>\n- If you are using
einstall<\/code>, remove it. I’m pretty sure you never really needed it. And\u00a0if you really did, then you most likely missed some custom prefix option in\u00a0upstream build system.<\/li>\n- If you are using
dohtml<\/code>, consider replacing it with dodoc -r<\/code>. You can set PORTAGE_DOHTML_WARN_ON_SKIPPED_FILES=yes<\/code> before doing that, to see if the\u00a0two will be equivalent.<\/li>\n- If you are inheriting base.eclass, autotools-utils.eclass or any of the\u00a0other banned eclasses, make sure to remove it from your eclasses and\u00a0ebuilds.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
Now that EAPI\u00a06 is Council-approved and\u00a0pretty close to being deployed, I think it’s about time to write up a\u00a0not-so-short guide to it. It’s especially important that EAPI\u00a06 is a\u00a0bit different from the\u00a0previous EAPIs. It was not only seen as an\u00a0opportunity to add new features but also to tidy things up a\u00a0bit and\u00a0improve strictness. If you … Continue reading “The Ultimate Guide to EAPI\u00a06”<\/span><\/a><\/p>\n","protected":false},"author":137,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[3],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/364"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/users\/137"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/comments?post=364"}],"version-history":[{"count":20,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/364\/revisions"}],"predecessor-version":[{"id":385,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/364\/revisions\/385"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/media?parent=364"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/categories?post=364"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/tags?post=364"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}