Bug#997948: FPC should provide a way to trigger automatic rebuild of
On 18/06/2023 09:45, Abou Al Montacir wrote: However, fpc units are kind of statically linked libraries. And in this case, one ma want a rebuild of all reverse dependencies in order to ensure a bug fix is propagated on all binaries. Example: Suppose we discover a vulnerability in a unit. We want that all units and all programs that use it be rebuilt, no? Setting the 'Static-Built-Using' field in the control files of packages built with fpc should fix this. Cheers, Peter
Bug#997948: [Pkg-pascal-devel] Bug#997948: Bug#997948: FPC should provide a way to trigger automatic rebuild of
Hi, On 17-06-2023 19:47, Abou Al Montacir wrote: 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. This sounds very aggressive as I think most of the time it's unneeded. As a release manager I prefer an *almost* good situation over a much overly strict situation. Maybe autopkgtests can help? If we block migration in situation where the rebuild should have happened, we're good. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#997948: [Pkg-pascal-devel] Bug#997948: FPC should provide a way to trigger automatic rebuild of
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
Bug#997948: FPC should provide a way to trigger automatic rebuild of
Hi Abou, On 18-02-2023 12:17, Abou Al Montacir wrote: On Thu, 2021-12-30 at 22:30 +0100, Abou Al Montacir wrote: Maybe we should move the fp-units-$bar packages to the library section too and embed the ABI version into the package name. I like that idea. Let's go that way. ... I don't think fp-unit-* make sense in the lib section. I think that the best place for /fp-units-*/ is /libdevel/ as they are very similar to the /foo-dev/ packages. Ack. what do you think? Will this solve the issue with regards to the release team script, or it handle only /lib/ section in that particular way? 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? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#997948: FPC should provide a way to trigger automatic rebuild of
Hi Paul, I went again though this ticket and changed a bit my mind On Thu, 2021-12-30 at 22:30 +0100, Abou Al Montacir wrote: > > Maybe we should move > > the fp-units-$bar packages to the library section too and embed the ABI > > version into the package name. > > > I like that idea. Let's go that way. ... > I don't think fp-unit-* make sense in the lib section. I think that the best place for fp-units-*is libdevel as they are very similar to the foo-dev packages. what do you think? Will this solve the issue with regards to the release team script, or it handle only lib section in that particular way? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
