Hi Paul, On Mon, 2023-02-20 at 20:57 +0100, Paul Gevers wrote: > The Release Team scripts don't care about the section, they look at > installability. But if we compare the units to C libraries, we normally > asks library maintainers to *not* version the dev packages, because then > all reverse build dependencies need an update when the SONAME gets > bumped, making the transition process very labor-some. > > What we want to achieve here is a way to ensure packages are rebuild > (semi) automatically when the units require it. But we *also* want to > come up with a way that doesn't require changes in the reverse > dependencies at the same time. Consider also that adding new binary > packages require a trip through NEW. Would it make sense that every unit > provides a virtual abi package, which get embedded in the dependencies > during build time, such that when a unit bumps the virtual abi, the > release team tools notice and rebuilds can be triggered? Or is that what > we already more or less do? We already have fpc-abi-x.y.z that handle this. However the problem of fpc-abi-* is that it does not carry a patch indicator. So one way to fix this is that if we change any interface, we should bump its version. Today we define it as fpc-abi-3.2.2. We can add a number like fpc-abi-3.2.2+p1, +p2, ... This way each time we change an interface of any unit we bump the patch number.
However, this will solve only the problem for FPC, but not for LCL or any other units supplied by other projects (like CGE). So maybe the solution would be to make the units dependency strict. I meant id fp-units-foo build depends on fp-unit-bar then it should depend on it strictly. And any rebuild of fp-units-bar shall trigger rebuild of fp-units-foo. -- Cheers, Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
