On Tue, 22 Feb 2022 13:21:48 +0100 Dr Rainer Woitok <rainer.woi...@gmail.com> wrote:
> And none of the examples to overcome problems provided by others in this > thread ever contained "--changed-deps". Does this mean "--changed-deps" > is a NOOP, a relict from days long gone by, meanwhile without any funct- > ionality, just provided for compatibility in order to not break ancient > scripts? It is kind of a noop. I am not 100% certain, but my interpretation is the following (based on experience with a binary host serving to several clients). I'm at timepoint T1 and I merge package pkg1, which depends on >=dep1:1.2.0 This is all merged at timepoint T1 and these dependencies are remembered in /var/db/pkg and also in $PKGDIR/Packages. Now comes timepoint T2 the ebuild was modified, no revbump whatsoever has been done, but suddenly the dependency reads as >=dev1:1.2.1. Now normally it is a noop to re-emerge because you are already on dev1:1.3, i.e. nothing really changes BUT it makes a difference for binary packaging. When you have a build-host that you to provide binaries, you can end up in situations where your client would reject a package due to unmatched dependencies (your build-host has emerged pkg1 at timepoint T1 and remembered that pkg1 depends on >=dep1:1.2.0), however you try to update the client at timepoint T2 where the >dependency is now >=dep1:1.2.1, and you'll end up in mismatched dependency and the binary will be rejected, i.e. your client must compile itself and cannot merge from the binary host. When you are not worried providing packages as binaries to other clients you probably should not care about --changed-deps.
