{"id":486,"date":"2016-06-22T22:26:14","date_gmt":"2016-06-22T20:26:14","guid":{"rendered":"https:\/\/blogs.gentoo.org\/mgorny\/?p=486"},"modified":"2018-08-13T18:16:57","modified_gmt":"2018-08-13T16:16:57","slug":"dependency-classes-and-allowed-dependency-types","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/mgorny\/2016\/06\/22\/dependency-classes-and-allowed-dependency-types\/","title":{"rendered":"Dependency classes and\u00a0allowed dependency types"},"content":{"rendered":"

In\u00a0my previous post<\/a> I have described a\u00a0number of\u00a0pitfalls regarding Gentoo dependency specifications. However, I have missed a\u00a0minor point of\u00a0correctness of various dependency types in\u00a0specific dependency classes. I am going to address this in\u00a0this short post.<\/p>\n

There are three classes of\u00a0dependencies in\u00a0Gentoo: build-time dependencies that are installed before the\u00a0source build happens, runtime dependencies that should be installed before the\u00a0package is installed to the\u00a0live system and\u00a0\u2018post\u2019 dependencies which are pretty much runtime dependencies whose install can be delayed if\u00a0necessary to avoid dependency loops. Now, there are some fun relationships between dependency classes and\u00a0dependency types.<\/p>\n

<\/p>\n

Blockers<\/h2>\n

Blockers are the\u00a0dependencies used to prevent a\u00a0specific package from being installed, or to force its uninstall. In\u00a0modern EAPIs, there are two kinds of\u00a0blockers: weak blockers (single !<\/kbd>) and\u00a0strong blockers (!!<\/kbd>).<\/p>\n

Weak blockers indicate that if\u00a0the\u00a0blocked package is installed, its uninstall may be delayed until the\u00a0blocking package is installed. This is mostly used to solve file collisions between two packages \u2014 e.g. it allows the\u00a0package manager to replace colliding files, then unmerge remaining files of the\u00a0blocked package. It can also be used if the\u00a0blocked package causes runtime issues on the\u00a0blocking package.<\/p>\n

Weak blockers make sense only in\u00a0RDEPEND<\/kbd>. While they’re technically allowed in\u00a0DEPEND<\/kbd> (making it possible for DEPEND=${RDEPEND}<\/kbd> assignment to be\u00a0valid), they are not really meaningful in\u00a0DEPEND<\/kbd> alone. That’s because weak blockers can be delayed post build, and\u00a0therefore may not influence the\u00a0build environment at all. In\u00a0turn, after the\u00a0build is done, build dependencies are no longer used, and\u00a0unmerging the\u00a0blocker does not make sense anymore.<\/p>\n

Strong blockers indicate that the\u00a0blocked package must be uninstalled before the\u00a0dependency specification is considered satisfied. Therefore, they are meaningful both for build-time dependencies (where they indicate the\u00a0blocker must be uninstalled before source build starts) and\u00a0for runtime dependencies (where they indicate it must be uninstalled before install starts).<\/p>\n

This leaves PDEPEND<\/kbd> which is a\u00a0bit unclear. Again, technically both blocker types are valid. However, weak blockers in\u00a0PDEPEND<\/kbd> would be pretty much equivalent to those in\u00a0RDEPEND<\/kbd>, so there is no reason to use that class. Strong blockers in\u00a0PDEPEND<\/kbd> would logically be equivalent to weak blockers \u2014 since the\u00a0satisfaction of this dependency class can be delayed post install.<\/p>\n

Any-of dependencies and\u00a0:* slot operator<\/h2>\n

This is going just to be a\u00a0short reminder: those types of\u00a0dependencies are valid in\u00a0all dependency classes but no binding between those occurences is provided.<\/p>\n

An\u00a0any-of dependency in\u00a0DEPEND<\/kbd> indicates that at\u00a0least one of\u00a0the\u00a0packages will be installed before the\u00a0build starts. An\u00a0any-of dependency in\u00a0RDEPEND<\/kbd> (or\u00a0PDEPEND<\/kbd>) indicates that at\u00a0least one of\u00a0them will be installed at runtime. There is no guarantee that the\u00a0dependency used to satisfy DEPEND<\/kbd> will be the\u00a0same as the\u00a0one used to satisfy RDEPEND<\/kbd>, and\u00a0the\u00a0latter is fully satisfied when one of the\u00a0listed packages is replaced by another.<\/p>\n

A\u00a0similar case occurs for :*<\/kbd> operator \u2014 only that slots are used instead of separate packages.<\/p>\n

:= slot operator<\/h2>\n

Now, the\u00a0\u2018equals\u2019 slot operator is a\u00a0fun one. Technically, it is valid in\u00a0all dependency classes \u2014 for the\u00a0simple reason of DEPEND=${RDEPEND}<\/kbd>. However, it does not make sense in\u00a0DEPEND<\/kbd> alone as it is used to force rebuilds of\u00a0installed package while build-time dependencies apply only during the\u00a0build.<\/p>\n

The\u00a0fun part is that for the\u00a0:= slot operator to be valid, the\u00a0matching package needs to be installed when the\u00a0metadata for the\u00a0package is recorded \u2014 i.e.\u00a0when a\u00a0binary package is created or the\u00a0built package is installed from source. For this to happen, a\u00a0dependency guaranteeing this must be in\u00a0DEPEND<\/kbd>.<\/p>\n

So, the\u00a0common rule would be that a\u00a0package dependency using :=<\/kbd> operator would have to be both in\u00a0RDEPEND<\/kbd> and\u00a0DEPEND<\/kbd>. However, strictly speaking the\u00a0dependencies can be different as long as a\u00a0package matching the\u00a0specification from RDEPEND<\/kbd> is guaranteed by DEPEND<\/kbd>.<\/p>\n","protected":false},"excerpt":{"rendered":"

In\u00a0my previous post I have described a\u00a0number of\u00a0pitfalls regarding Gentoo dependency specifications. However, I have missed a\u00a0minor point of\u00a0correctness of various dependency types in\u00a0specific dependency classes. I am going to address this in\u00a0this short post. There are three classes of\u00a0dependencies in\u00a0Gentoo: build-time dependencies that are installed before the\u00a0source build happens, runtime dependencies that should be … Continue reading “Dependency classes and\u00a0allowed dependency types”<\/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":[11],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/486"}],"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=486"}],"version-history":[{"count":6,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/486\/revisions"}],"predecessor-version":[{"id":492,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/486\/revisions\/492"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/media?parent=486"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/categories?post=486"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/tags?post=486"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}