Bug#91815: Patch to add memusage and memusagestat

[Helmut Grohne <helmut@subdivi.de>]

Hi Aurelien and Stephen,

On Wed, Apr 22, 2020 at 12:04:32AM +0200, Aurelien Jarno wrote:
> > The attached patch adds memusage and memusagestat to the libc-bin package.
> > This does mean that the latter becomes dependent on libgd3, so it might be
> > better to add a new memusage package; I can take care of that if the
> > maintainers think it’s better.
> 
> I am not sure we want to add a new dependency for libc-bin, I am sure
> people running embedded systems won't appreciate. Any reason for not
> shipping it in libc-dev-bin instead? For me that looks more like a tool
> to be used for "development". At least the memusagestat is similar to
> the mtrace one that is in libc-dev-bin.
> 
> We also have to make sure that this new build-dependency doesn't break
> bootstrapping. I have added Helmut in Cc so that he can have a look.

Thank you for notifying me. Indeed, the patch doesn't work for
bootstrapping as is. A stage2 build of glibc would start requiring
libgd-dev -> libgd3 -> libc6, but the stage1 libc6 will not be
sufficient to build src:libgd2. It must be possible to build stage2
without that dependency.

(Note that this is going to become more confusing as there is ongoing
work on removing stage1 and maybe renaming stage2, but let's stick to
the current names for now.)

>From a bootstrapping pov, the libgd-dev dependency is similar to the
libselinux-dev dependency, but I notice just now that it is not
correctly annotated with <!stage2> in Build-Depends!

>From a build profile pov, it is very undesirable to have package
contents change with profiles. Doing so makes it impossible to validate
them using reproducible builds. However, since we need libc6-dev from
stage2 and it depends on libc-dev-bin we cannot skip generating
libc-dev-bin in stage2. I wonder whether it would make sense to add
another binary package for development tools that are not normally
needed for building software. Then we could skip generating that
package. mtrace would be a good candidate to join that package indeed.

Failing that, we'll have to cope with changing package contents for
stage2 and disable the new dependency for stage2 (or some other
profile).

Helmut