Hi, On Sat, 16 May 2020 13:35:02 +0200, Aurelien Jarno <aurel32@debian.org> wrote: > On 2020-05-09 12:27, Helmut Grohne wrote: > > 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 don’t mind, it’s not as if this is an urgent bug ;-). > 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. I went for libc-devtools to avoid making it too closely-tied to libc-dev-bin, on purpose; it’s not only useful for people needing libc-dev. > > 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’ve implemented this, see the attached patch. I’m not sure the upgrade scenario is ideal though: recommends are ignored on upgrades. This means that, if libc-dev-bin recommends libc-devtools, upgrades won’t install the latter, but new installations of libc-dev-bin will. Pushing memusage* to a separate package would result in that being installed on upgrade: libc-dev-bin would depend on libc-devtools (following the transition rules strictly), so that would get pulled in automatically on upgrade, and since it’s a new package, it would count as installation, and thus pull in its recommendations. > I don't know if it's something that's acceptable. What do you think? > Maybe we should ask the release team? That would be useful! I need to check the upgrades scenarios again, I’ll reach out to them in a couple of weeks’ time, unless you want to do it directly. Regards, Stephen
From 95f482efe7c2ae6d9a87d0a47cd5619cb26a4f55 Mon Sep 17 00:00:00 2001
From: Stephen Kitt <skitt@debian.org>
Date: Tue, 21 Apr 2020 20:55:53 +0200
Subject: [PATCH] Build and package memusage*
This builds memusage and memusagestat in the libc pass, and ships them
in a new package, libc-devtools (short for "libc-provided developer
tools", and not libc-dev-tools to avoid making it seem to
closely-related to libc-dev-bin). This involves adding a
build-dependency on libgd-dev (outside stage1 and stage2). Other tools
which are not used to build *with* libc, but useful for development in
general, are moved to libc-devtools: mtrace, sotruss, sprof.
libc-dev-bin recommends libc-devtools to provide a simple
transition (see #91815 for the discussion).
Closes: #91815
Signed-off-by: Stephen Kitt <skitt@debian.org>
---
debian/control.in/main | 25 +++++++++++++++++--
debian/debhelper.in/libc-dev-bin.install | 3 ---
debian/debhelper.in/libc-dev-bin.manpages | 1 -
debian/debhelper.in/libc-devtools.install | 5 ++++
...rrides => libc-devtools.lintian-overrides} | 2 ++
debian/debhelper.in/libc-devtools.manpages | 1 +
debian/rules | 3 +++
debian/rules.d/build.mk | 8 ++++++
8 files changed, 42 insertions(+), 6 deletions(-)
create mode 100644 debian/debhelper.in/libc-devtools.install
rename debian/debhelper.in/{libc-dev-bin.lintian-overrides => libc-devtools.lintian-overrides} (58%)
create mode 100644 debian/debhelper.in/libc-devtools.manpages
diff --git a/debian/control.in/main b/debian/control.in/main
index 659267bd..c513a01a 100644
--- a/debian/control.in/main
+++ b/debian/control.in/main
@@ -12,7 +12,8 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>= 1.17.14), xz-utils, file,
g++-9, g++-9-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc ppc64 s390x sparc sparc64 x32] <!nobiarch>,
python3:native,
libidn2-0 (>= 2.0.5~) <!nocheck>,
- libc-bin (>= @GLIBC_VERSION@) <cross>
+ libc-bin (>= @GLIBC_VERSION@) <cross>,
+ libgd-dev <!stage1> <!stage2>
Build-Depends-Indep: perl, po-debconf (>= 1.0)
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Uploaders: Clint Adams <clint@debian.org>, Aurelien Jarno <aurel32@debian.org>, Adam Conrad <adconrad@0c3.net>, Samuel Thibault <sthibault@debian.org>
@@ -47,11 +48,31 @@ Section: libdevel
Priority: optional
Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: manpages, manpages-dev
+Recommends: libc-devtools (>> @GLIBC_VERSION@)
Build-Profiles: <!stage1>
Description: GNU C Library: Development binaries
This package contains utility programs related to the GNU C Library
development package.
+ .
+ * gencat: generate message catalogs
+ * rpcgen: compile RPC protocols to C
+
+Package: libc-devtools
+Architecture: any
+Section: devel
+Priority: optional
+Multi-Arch: foreign
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Recommends: manpages, manpages-dev
+Build-Profiles: <!stage1> <!stage2>
+Description: GNU C Library: Development tools
+ This package contains development tools shipped by the GNU C
+ Library.
+ .
+ * memusage, memusagestat: profile a program's memory usage
+ * mtrace: interpret the malloc trace log
+ * sotruss: trace shared library calls
+ * sprof: display shared object profiling data
Package: libc-l10n
Architecture: all
diff --git a/debian/debhelper.in/libc-dev-bin.install b/debian/debhelper.in/libc-dev-bin.install
index 0d760a7e..902029b5 100644
--- a/debian/debhelper.in/libc-dev-bin.install
+++ b/debian/debhelper.in/libc-dev-bin.install
@@ -1,5 +1,2 @@
debian/tmp-libc/usr/bin/gencat usr/bin
-debian/tmp-libc/usr/bin/mtrace usr/bin
debian/tmp-libc/usr/bin/rpcgen usr/bin
-debian/tmp-libc/usr/bin/sotruss usr/bin
-debian/tmp-libc/usr/bin/sprof usr/bin
diff --git a/debian/debhelper.in/libc-dev-bin.manpages b/debian/debhelper.in/libc-dev-bin.manpages
index c33123a0..576ec52c 100644
--- a/debian/debhelper.in/libc-dev-bin.manpages
+++ b/debian/debhelper.in/libc-dev-bin.manpages
@@ -1,3 +1,2 @@
debian/local/manpages/gencat.1
debian/local/manpages/rpcgen.1
-debian/local/manpages/sotruss.1
diff --git a/debian/debhelper.in/libc-devtools.install b/debian/debhelper.in/libc-devtools.install
new file mode 100644
index 00000000..7a0024da
--- /dev/null
+++ b/debian/debhelper.in/libc-devtools.install
@@ -0,0 +1,5 @@
+debian/tmp-libc/usr/bin/memusage usr/bin
+debian/tmp-libc/usr/bin/memusagestat usr/bin
+debian/tmp-libc/usr/bin/mtrace usr/bin
+debian/tmp-libc/usr/bin/sotruss usr/bin
+debian/tmp-libc/usr/bin/sprof usr/bin
diff --git a/debian/debhelper.in/libc-dev-bin.lintian-overrides b/debian/debhelper.in/libc-devtools.lintian-overrides
similarity index 58%
rename from debian/debhelper.in/libc-dev-bin.lintian-overrides
rename to debian/debhelper.in/libc-devtools.lintian-overrides
index eedd7cbd..1031449a 100644
--- a/debian/debhelper.in/libc-dev-bin.lintian-overrides
+++ b/debian/debhelper.in/libc-devtools.lintian-overrides
@@ -1,3 +1,5 @@
# these manpages are provided by the manpages package
+libc-dev-bin: binary-without-manpage usr/bin/memusage
+libc-dev-bin: binary-without-manpage usr/bin/memusagestat
libc-dev-bin: binary-without-manpage usr/bin/mtrace
libc-dev-bin: binary-without-manpage usr/bin/sprof
diff --git a/debian/debhelper.in/libc-devtools.manpages b/debian/debhelper.in/libc-devtools.manpages
new file mode 100644
index 00000000..c43e02da
--- /dev/null
+++ b/debian/debhelper.in/libc-devtools.manpages
@@ -0,0 +1 @@
+debian/local/manpages/sotruss.1
diff --git a/debian/rules b/debian/rules
index 97e00f91..84bddc48 100755
--- a/debian/rules
+++ b/debian/rules
@@ -136,6 +136,9 @@ ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
endif
else
DEB_ARCH_REGULAR_PACKAGES = $(libc) $(libc)-dev $(libc)-dbg $(libc)-pic libc-bin libc-dev-bin
+ ifeq ($(filter stage2,$(DEB_BUILD_PROFILES)),)
+ DEB_ARCH_REGULAR_PACKAGES += libc-devtools
+ endif
DEB_INDEP_REGULAR_PACKAGES = glibc-doc glibc-source libc-l10n locales
ifneq ($(filter noudeb,$(DEB_BUILD_PROFILES)),)
DEB_UDEB_PACKAGES =
diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk
index 0d03116a..7dbe9024 100644
--- a/debian/rules.d/build.mk
+++ b/debian/rules.d/build.mk
@@ -37,7 +37,15 @@ $(stamp)configure_%: $(stamp)config_sub_guess $(stamp)patch $(KERNEL_HEADER_DIR)
echo "BASH := /bin/bash" >> $(DEB_BUILDDIR)/configparms
echo "KSH := /bin/bash" >> $(DEB_BUILDDIR)/configparms
echo "SHELL := /bin/bash" >> $(DEB_BUILDDIR)/configparms
+ifeq (,$(filter stage1 stage2,$(DEB_BUILD_PROFILES)))
+ if [ "$(curpass)" = "libc" ]; then \
+ echo "LIBGD = yes" >> $(DEB_BUILDDIR)/configparms; \
+ else \
+ echo "LIBGD = no" >> $(DEB_BUILDDIR)/configparms; \
+ fi
+else
echo "LIBGD = no" >> $(DEB_BUILDDIR)/configparms
+endif
echo "bindir = $(bindir)" >> $(DEB_BUILDDIR)/configparms
echo "datadir = $(datadir)" >> $(DEB_BUILDDIR)/configparms
echo "complocaledir = $(complocaledir)" >> $(DEB_BUILDDIR)/configparms
--
2.20.1
Attachment:
pgpau8zMkjAwX.pgp
Description: OpenPGP digital signature