Bug#91815: Patch to add memusage and memusagestat
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
aurelien@aurel32.net http://www.aurel32.net
Reply to: