
<html><head></head><body><div>Hi Paul,</div><div><br></div><div>On Sat, 2021-10-30 at 15:21 +0200, Paul Gevers wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>So all libraries need a Depends on a binary from src:fpc with an upper<br>limit (generated during the build).</div></blockquote><div>In some sense, this is done as any FPC library should depend on RTL package fp-units-rtl-${UPSTREAM_VERSION} with >= condition.</div><div>This implies that if 3.2.2 is introduced instead of 3.2.0 then the library in the repository is not usable anymore.</div><div>However in practice, the upgrade of FPC will leave old version installed and thus users will be able to continue using old library with old compiler.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div> In that way, the Debian<br>infrastructure knows that a rebuild (or potentially manual action) is<br>needed. We don't want it to be too tight.</div></blockquote><div>I don't know exactly hos Debian infrastructure decides to rebuild or not a package, but what I can imagine is that view3dscene build depends on castle-engine (which depends on fp-units-rtl-3.2.0) and on fp-compiler.</div><div>In this case fp-compiler will be pulled as 3.2.2 and will drag fp-units-rt-3.2.2 while fp-units-rtl-3.2.0 will be dragged by direct dependency.</div><div>In this case, the build system thinks it has got all dependencies but in reality, ppu files of castle-engine, that are compiled with fp-compiler 3.2.0 will net be usable by 3.2.2 compiler.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div> When you said "any new version<br>of FPC" do you mean each patch level too, or on only minor level? How<br>about Debian new uploads?</div></blockquote><div>For a ppu to be used by the compiler is should:</div><ol><li>have the same ppu version as the one supported by the compiler. This may not be the case between different upstream releases.</li><li>be compiled with an RTL version that have the very same interface for used units. If any unit from RTL changed interface, then the compiler will fail to use it and will ask for recompiling the library unit that is using it. It is important to note that changes of the code of any inline function is considered as an interface change (think as in C inlines functions are in .h files).</li><li>be compiled using -Ur flag to avoid the compiler to try to recompile it if implementation is changed (this happens usually after a bug fix).</li></ol><div style="caret-color: rgb(46, 52, 54); color: rgb(46, 52, 54); font-family: Cantarell; font-size: 14.666666984558105px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;"><span><div><br></div><div>When we upload a new Debian version, we are generally changing implementation. This is falls under the case number 3. We should be safe and would not need to recompile anything.</div><div><br></div><div>I hope this makes the situation clearer.<br class="Apple-interchange-newline">-- <br></div><pre>Cheers,

Abou Al Montacir</pre></span></div></body></html>