Source: e2fsprogs Version: 1.47.1-1 Severity: important User: helm...@debian.org Usertags: rebootstrap X-Debbugs-Cc: jo...@debian.org
e2fsprogs gained a build dependency on libarchive-dev recently. The added functionality is super useful, but the added dependency comes with a problem attached. src:libarchive happens to build depend on libext2fs-dev and there we have a cycle. Since this is a library dependency in each direction, it fully affects cross bootstrap. I see a few options. One is adding a pkg.e2fsprogs.nolibarchive build profile that disables this new dependency and allows building e2fsprogs without, then building libarchive and then building a full e2fsprogs. >From my point of view, this works, but it is annoying as the tooling doesn't deal with build profiles in a great way and we also incur more build time here slowing down architecture bootstrap. How about separating the availability of libarchive from the interest in supporting libarchive? Since it is runtime-loaded using dlopen, e2fsprogs already carries the prototypes for most libarchive functions and doesn't actually need to #include them. What it does not yet do is carry forward declarations "struct archive;" and "struct archive_entry;". Adding these would likely allow building e2fsprogs with libarchive support, but without using libarchive-dev at build time. Of course #including it is a good idea to locate problems, so in the common case, we'd want to actually use it. What I am effectively proposing here is adding another --with-libarchive value that should produce the same binary result as --with-libarchive=yes (dlopen), but work without any access to libarchive headers. Then, libarchive-dev could be annotated <!nocheck> and all regular builds would remain unchanged. Helmut
