Per PMS [1]: | REPLACING_VERSIONS is a list, not a single optional value, to handle | pathological cases such as installing foo-2:2 to replace foo-2:1 and foo-3:2. It should be noted that as the author [2] explains this is just an example of pathological case and not the only possibility. In any case, PMS explicitly requires ebuilds to account for possible multiple values. The overhead of such a check is really minimal, and therefore is not a valid excuse not to follow the spec. An example of correct REPLACING_VERSIONS check: pkg_postinst() { local v for v in ${REPLACING_VERSIONS}; do if ! version_is_at_least ... ${v}; then ... # if the thingie should be done at most once: break fi done } [1]:https://projects.gentoo.org/pms/6/pms.html#x1-12000011.1.2 [2]:https://archives.gentoo.org/gentoo-dev/message/dc975c9e64011a34dd98d0ffa5b23ee6
(In reply to Michał Górny from comment #0) > Per PMS [1]: > > | REPLACING_VERSIONS is a list, not a single optional value, to handle > | pathological cases such as installing foo-2:2 to replace foo-2:1 and > foo-3:2. > > It should be noted that as the author [2] explains this is just an example > of pathological case and not the only possibility. > More specifically -- the case for a single-slot-only package where ${REPLACING_VERSIONS} might have more than one value is (apparently) when a previous emerge of an upgrade or downgrade fails to complete during the merge process. As such, when coding the list-capable version it is good to keep in mind that if there are two versions in the list then one (or both) of them might be an incomplete merge, and also that there's no way to know which one is which. This doesn't much matter when ${REPLACING_VERSIONS} is conditionally displaying elog messages, but it could matter a lot when wrapping calls to tools, doing configuration updates, etc.
