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