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

On Sat, Feb 14, 2026 at 11:39:36AM -0500, Kris Van Hees wrote:
> On Sat, Feb 14, 2026 at 01:34:31PM +0000, Sam James wrote:
> > Nick Alcock via DTrace-devel <[email protected]> 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?

Following up to myself... perhaps we should improve the configure script to
be compliant with the GNU Coding Standards expectations of a configure script,
which would avoid all this...  It would require us to accept the currently
unrecognized options for paths, and support --disable-option-checking which
will allow us to silently ignore unknown --with/without-* --enable/disable-*
options.

I would assume that will satisfy the requirements of pretty much all distros,
incl. Gentoo and Debian?

From what I can see, it should be quite trivial to do.  We'd need to include
config.sub and config.guess I expect (unless we can pull in systemwide versions
of that using a dependency), and need to generate a config.status script, but
none of that is difficult.