On Wed, Dec 27, 2023 at 12:04 AM Richard Laager <rlaa...@debian.org> wrote: > > On 2023-12-26 02:38, Martin-Éric Racine wrote: > > On Mon, Dec 25, 2023 at 12:20 AM Richard Laager <rlaa...@debian.org> wrote: > >> If past me was correct, without systemd at build-time, waf will not > >> install the systemd units. Then we will end up with other failures in > >> debian/rules or from the .install files. > > > > Not installing them on platforms where systemd has not been ported is > > the correct action. > > Agreed. My point was that additional work would be required, during the > package building process, to not blow up when those files are missing > from `waf install`.
Looking at the diff for the Hurd port would tell you what's needed. Anything else is speculation. > > It built enough to have ntpdate. > bin:ntpdate is just a transitional package to transition uses of the old > src:ntp's bin:ntpdate to src:ntpsec's bin:ntpsec-ntpdate. It is > Architecture: all, which is why it is available on Hurd. > > In ntpsec, the ntpdate executable is just a thin wrapper around ntpdig, > which ships in the bin:ntpsec-ntpdig package (formerly, it was in > bin:ntpsec-ntpdate). While ntpdig is Python, so it doesn't actually > require compilation, it is presumably going to require some build steps > happen. Noted. > >> ifeq (hurd, $(DEB_HOST_ARCH_OS)) > >> # hurd does not provided the system calls needed for ntpd to work. > >> exit 1 > >> endif > >> > >> I see a couple of ways forward here: > >> > >> A) I properly indicate this package does not support HURD. > >> > >> I think I would just replace the "Architecture: any" with > >> "Architecture: linux-any" on binary packages in debian/control, but > >> I would love confirmation on that. > > > > Which is what this bug requested > > I'm confused. > > What you asked for was for me to limit "Build-Depends: systemd" to > [linux-any]. Which is the correct course of action. Puposely limiting binary targets isn't. Martin-Éric
