[DTrace-devel] [PATCH v4] Add packaging configuration for Debian

[Kris Van Hees]

On Sat, Feb 14, 2026 at 01:34:31PM +0000, Sam James wrote:
> Nick Alcock via DTrace-devel <dtrace-devel at oss.oracle.com> writes:
> 
> > On 10 Feb 2026, Kris Van Hees via DTrace-devel outgrape:
> >
> >> Packaging configuration files for Debian are provided in dists/debian.
> >
> > Nice! Seems to work, even on Debian stable (I was sure I'd need at least
> > testing, but no!).
> >
> > [...]
> >> diff --git a/dists/debian/patches/debian-configure.patch b/dists/debian/patches/debian-configure.patch
> >> new file mode 100644
> >> index 00000000..d4a89bb9
> >> --- /dev/null
> >> +++ b/dists/debian/patches/debian-configure.patch
> >> @@ -0,0 +1,17 @@
> >> +Description: issue a warning for unknown configure options
> >> + The Debian build system specifies configure options that are not known to
> >> + the DTrace configure script.  They should not cause the configure script
> >> + to abort.
> >> +--- dtrace-2.0.4.orig/configure
> >> ++++ dtrace-2.0.4/configure
> >> +@@ -172,8 +172,7 @@ for option in "$@"; do
> >> +         HAVE_VALGRIND=*) write_config_var VALGRIND "$option";;
> >> +         HAVE_BPFV3=*) write_config_var BPFV3 "$option";;
> >> +         HAVE_BPFMASM=*) write_config_var BPFMASM "$option";;
> >> +-        *) echo "Unknown option $option" >&2
> >> +-           exit 1;;
> >> ++        *) echo "Unknown option $option" >&2;;
> >> +     esac
> >> + done
> >
> > I assumed you could just stuff an || true in there, but this is being
> > invoked by dh_auto_configure, so that option isn't available (plus, of
> > course, if there's an actual error other than unknown args, we don't
> > want to fail).
> >
> > Maybe we should just not exit with exitcode 1 on unknown configure
> > options, only IIRC Gentoo actually wants us to. This may be the best we
> > can do.
> 
> I really doubt this is the first / only package for Debian where there's
> a non-autoconf configure script.
> 
> The real issue here is letting whatever Debian machinery that calls
> configure think it is autoconf. ebuilds do the same, by default econf
> will pass things assuming it's autoconf.
> 
> I'm sure there's a way to override that?

Well, while the configure script Nick wrote isn't autoconf, I believe he did
make it accept optionsn autoconf's configure style and naming.  That said, the
script does not support all the options that autoconf's configure scripts
could accept (and that are passed by dh_auto_configure).  Hence this patch.

I guess we could replace the dh_auto_configure invocation with an explicit
invocation of our configure script, but then we need to figure out all the
explicit options we do need to pass to set various paths correctly based on
the build system configuration.  That seems to me like replicating work that
is already done for us by dh_auto_configure.  None of the options we ignore
are actually relevant (and if in the future, they are, we'd need to patch
our configure script anyway).

So I would be inclined to argue that ignoring the unrecognized options is not
a bad option.  It reports what is being ignored.

Alternatively, I'd suggest we update the configure script to actually support
the options that we get complaints about right now, providing an implementation
that makes sense (accept and ignore some, accept and use some others).

I could go either way here.  I don't think one is worse than the other, aside
from having 'accept and ignore' cases feeling a bit less ideal to me because
it hides the 'ignore' effect (unless you print a message we're ignoring it and
then we're back to my current solution anyway).

Thoughts?

> >
> >> diff --git a/dists/debian/patches/debian-interpreter-paths.patch b/dists/debian/patches/debian-interpreter-paths.patch
> >> new file mode 100644
> >> index 00000000..58bea538
> >> --- /dev/null
> >> +++ b/dists/debian/patches/debian-interpreter-paths.patch
> >> @@ -0,0 +1,107 @@
> >> +Description: fix interpreter paths in tests
> >> + Lintian prefers /bin/bash and /bin/sed over /usr/bin/bash and /usr/bin/sed.
> >
> > Honestly this one I think we should do upstream. I always thought that
> > /bin/bash is universal and /usr/bin/bash less so.
> >
> 
> Yes.

Done.

> > [...]
> 
> sam