Hi Aurélien, hi Helmut, On Mon, 4 May 2020 07:11:37 +0200, Helmut Grohne <helmut@subdivi.de> wrote: > On Mon, May 04, 2020 at 12:00:28AM +0200, Aurelien Jarno wrote: > > Thanks for the detailed explanations. It looks to me that it's better to > > add a different package. And while mtrace looks a good candidate to join > > this package, I am not sure we can handle the transition easily. It > > would mean that libc6-dev-bin need to depends on that new package at > > least for one release cycle. And we actually don't want that for stage > > 2, which means producing different packages for stage2... > > Let me point out that a transitional dependency is not a huge cost to > reproducibility. Making the dependency optional to stage2 is reasonable. > libc packages are not yet reproducible across stages. That's more of a > vision. In diffoscope, such a dependency difference is very light. There’s another part of the transition which bothers me: if we add memusage to a package which is depended upon (albeit temporarily) by libc-dev-bin, it becomes part of build-essential, and adding memusage means adding libgd3, libfontconfig1, libfreetype6, etc. to all builds... It occurred to me that there is however a way to add memusage while transitioning cleanly, over a few years. It seems to me that the binaries in libc-dev-bin can be split into two categories: binaries that are expected as build tools (gencat and rpcgen), and binaries that are useful as tools for understanding programs but not building them (memusage, memusagestat, mtrace, sotruss, sprof). How about the following? * We add a new package, say libc-devtools, containing the second type of tools (mtrace, sotruss, sprof). For transition purposes, libc-dev-bin depends on that in Bullseye. * We add another package, memusage, containing memusage and memusagestat. That’s the package which ends up with all the annoying extra dependencies, but nothing depends on it. * In Bookworm, libc-dev-bin can drop the dependency on libc-devtools, and we can merge memusage into libc-devtools. Does that make sense? Regards, Stephen
Attachment:
pgphz7TA0o_2R.pgp
Description: OpenPGP digital signature