On Mon, Dec 26, 2022 at 08:37:51AM +0200, Peter Pentchev wrote: > Hi, > > In #1020403 there is a request to install the CMake build glue for > the zstd library in its -dev package. I think that this is a good > idea, and I have a pretty much ready-for-uploading set of changes > that do that. For the purposes of this discussion I have uploaded > the proposed "switch to CMake and install the CMake build glue" > commits to my own fork of the libzstd repository at > https://salsa.debian.org/roam/libzstd > > The main thing that gave me a bit of a pause before running > `dgit push-source` (and *thanks* for making it that easy!) is that > right now libzstd is effectively an essential package (ObXThread: > not in the Policy sense) since dpkg pre-depends on it to support > e.g. recent Ubuntu debs that use zstd as the compression method for > the data part of the package. So... if I introduce a build-time > dependency on CMake, this will probably create a non-trivial dependency > loop for people who try to bootstrap Debian onto new architectures. > Does this mean that it would be best for me to include an e.g. stage1 > build profile that does not build-depend on cmake and falls back to > the old/current way of building directly using `make`? > > Hm, but if I do that, it seems that it might be best to put the CMake > build glue files into a separate package and make libzstd-dev depend on > that new package in the <!stage1> case, since IIUC the stage1 build > profile is not allowed to change the contents of a binary package, so > I cannot simply drop all the files in the /usr/lib/<arch>/cmake/ directory. > That's not a big hurdle; if people say that this is the way to go, then > this is what will be done. > > Many thanks to all the people who keep working on all the tools and > toolchains that make this message make sense at all! Hm, I just thought of a hybrid solution, but I don't think it would be a really, really good idea: keep the non-cmake build, but also invoke cmake with a modified lists file so that it *only* generates the build glue; then still put that in a separate package, all of that governed by a !stage1 build profile. I'm not sure I like it a lot, since that would mean that the shipped library is not actually compiled using CMake, so one might say the cmake build glue is a lie... but it could be an option if people think it's best. G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature