Bug#264039: Patch to add memusage and memusagestat
- To: 264039@bugs.debian.org
- Subject: Bug#264039: Patch to add memusage and memusagestat
- From: Josh Triplett <josh@joshtriplett.org>
- Date: Sun, 3 Jan 2021 13:26:56 -0800
- Message-id: <X/I2oNCU4OdxUT9K@localhost>
- Reply-to: Josh Triplett <josh@joshtriplett.org>, 264039@bugs.debian.org
- In-reply-to: <X/HOJjSRmlR9VPZA@aurel32.net>
- References: <20200421205856.64a8044a@heffalump.sk2.org> <E1BtBkT-0007Qo-00@orion> <X+rT+w6RsV4b0RHc@localhost> <X/HOJjSRmlR9VPZA@aurel32.net> <E1BtBkT-0007Qo-00@orion>
On Sun, 3 Jan 2021 15:01:10 +0100 Aurelien Jarno <aurelien@aurel32.net> wrote:
> On 2020-12-28 23:00, Josh Triplett wrote:
> > On Tue, 21 Apr 2020 20:58:56 +0200 Stephen Kitt <skitt@debian.org> 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 do think it makes sense to have these in a separate package. Would you
> > consider moving libmemusage.so to that same separate package?
>
> This is not something doable, we can't mix binaries and libraries in the same
> packages. Libraries have to be in a Multi-Arch: same package, while
> binaries have to be in a Multi-Arch: foreign package.
You're right, sorry about that. I hadn't been thinking about multiarch
because libmemusage.so was a private non-versioned library, but that
*is* still an issue regardless.
That said, the actual memusage.sh script appears to hardcode the
shared-library directory at compile time, and the patch here doesn't
change that.
Reply to: