Hi Nilesh,

On Sun, May 19, 2024 at 12:27:02PM +0530, Nilesh Patra wrote:
> Julian Gilbey <j...@debian.org>:
> >  I have come across a number of packages with a line in their
> >  debian/rules like:
> >  
> >  ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
> >  
> >  This should be "nodoc", according to the "nodoc" entry in
> >  https://wiki.debian.org/BuildProfileSpec#Registered_profile_names
> >  
> >  It would be good to check for this error.
> 
> This mostly looks like a typo and I am kinda sure that you'd find typos like
> this all over many places. I am a bit unsure if checks for this is something 
> we
> as a new lintian warning is something that we even need?

Perhaps, perhaps not.  It's not something that's easily spotted by
eye unless you're explicitly looking for it.

> Louis-Philippe Véronneau <po...@debian.org>:
> > ...
> > I've created a patch on Salsa that creates a new Lintian check for this.
> > 
> > https://salsa.debian.org/lintian/lintian/-/merge_requests/504
> 
> And if we do --  I checked the MR and it does not look extensible. If in
> future there comes another class of typos, it will result in a new patch of 
> this
> kind. Instead, is it possible to have a list of offending terms like this in a
> data list and warn the user about them via a lintian warning?
> 
> For instance, we have data/fields/obsolete-packages for listing obsolete
> packages and showing the user about the obsolete packages and their
> replacements. Do you think a similar implementation for this
> (data/fields/bad-buildprofiles ?) makes sense?

Now *that's* a really nice approach.  But here I'd suggest doing the
opposite: checking for valid build options (and note: this is a check
for DEB_BUILD_OPTIONS, not for DEB_BUILD_PROFILES).  There is a very
short list of standard build options: those listed in
dpkg-buildpackage(1) (parallel=n, nocheck, noopt, nostrip, terse,
hardening=..., reproducible=..., abi=..., future=..., qa=...,
optimize=..., sanitize=...) and
https://wiki.debian.org/BuildProfileSpec: nodoc

Best wishes,

   Julian

Reply via email to