Bug#91815: Patch to add memusage and memusagestat
Hi,
On 2020-04-22 06:53, Helmut Grohne wrote:
> 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!
It's something we can fix. I found strange nobody notice so far. Does it
mean the bootstrap is done ignoring the build-dependencies?
> >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.
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...
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: