Hi Paul, > So, where should this tight dependency be recorded? Should we teach some > binary from castle-game-engine to be strict about some src:fpc counterpart? Normally, any new version of FPC should trigger a rebuild of the entire libraries (not programs) packaged for FPC. The reason is that FPC keeps units interface information in a ppu file that is compiler version depended, but also RTL dependent (each ppu will hold a kind of checksum on used unit files). This is both an advantage and a drawback against C were interface is distributed in a source (header) file. The advantage is that is will be faster, the drawback is that you need a __potential__ rebuild after each compiler/RTL upgrade. > > "Just" rebuilding is not the solution to paper over such an issue, we'd > need to prevent it from going unnoticed next time. It should show up on > https://release.debian.org/transitions/ with an auto-upperlimit-fpc > transition such that the release team is automatically warned that > rebuilds are needed and to prevent fpc from migrating until the rebuild > happened and is ready to migrate too. I don't know for now how to handle this efficiently. but the easiest way is to say, each new upload of FPC triggers all libraries (not programs) rebuild. -- Cheers, Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
