Bug#91815: Patch to add memusage and memusagestat
Hi Stephen, Thank you for not dropping the ball after my initial "it's not that easy" reply. On Sat, May 09, 2020 at 10:53:10AM +0200, Stephen Kitt wrote: > 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? All of what you write here makes very much sense to me and the trade-offs seem good to me. What you propose will result in making the bootstrapping/profile stuff simpler/better. That said, I am not a glibc maintainer. I don't see the full picture. I have two minor remarks: * Should libc-devtools maybe recommend memusage already? * We cannot simply have libc-devtools absorb memusage in bookworm. Doing so would break upgrades when someone has memusage, but not libc-devtools installed. Therefore memusage likely needs to be a transitional dummy package in bookworm and can only be removed one release later. I'm wondering whether this could be avoided if we had memusage depend on libc-devtools. Neither of these touch the core of your thoughts. I'm happy to review patches to make this happen. Please continue to Cc me if you want my review. Helmut
Bug#91815: Patch to add memusage and memusagestat
Hi Aurélien, hi Helmut, On Mon, 4 May 2020 07:11:37 +0200, Helmut Grohne 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 pgpCZZtK9enyl.pgp Description: OpenPGP digital signature
