Hi Stephen, hi Helmut, On 2020-05-09 12:27, Helmut Grohne wrote: > 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?
Yes, with the points raised by Helmut, I think it makes sense. Unfortunately many changes in glibc requires transitions lasting many years... I just wonder if we should call it libc-devtools or libc-dev-tools to match the pattern from libc-dev-bin. But that's a minor detail over the whole plan. > 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? It's something we can do, I think it mostly depends if we basically want libc-dev-bin to recommends memusage. > * 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. I agree with that. > Neither of these touch the core of your thoughts. Another faster alternative that came to my mind is to rely n the fact that recommends are enabled by default, but not used to resolve build-dependencies. In that case we can already create libc-devtools with memstatusage and also move mtrace, sotruss, sprof there. Those 3 binaries are very unlikely to be used to build packages, so I don't expect breakages. From the user point of view, it's just like if (part of) a dependency has been demoted to a recommends. It's something that is often done for other packages, and it seems we accept that even if it causes breakages (latest example that comes to my mind is util-linux dropping the dependency on fdisk). I guess adding an entry in NEWS would be necessary though. I don't know if it's something that's acceptable. What do you think? Maybe we should ask the release team? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net