Re: Please help to fix outdated SUBST blocks

[Roland Illig <roland.illig%gmx.de@localhost>]

On 04.05.2020 20:54, Joerg Sonnenberger wrote:
> On Mon, May 04, 2020 at 08:41:59PM +0200, Roland Illig wrote:
> > On 04.05.2020 13:26, Patrick Welche wrote:
> > > I see adwaita-icon-theme in Jonathan's list. I can argue the case both
> > > ways - thoughts?
> > >
> > > $ cat adwaita-icon-theme.pc.in
> > > Name: gnome-icon-theme
> > > Description: A collection of icons used as the basis for GNOME themes
> > > Version: @VERSION@
> > > Requires:
> > > Libs:
> > > Cflags:
> > >
> > > so it contains no variables that need to be overridden => get rid
> > > of the PKGCONFIG_OVERRIDE.
> > >
> > > In the unlikely event that a variable is added, I wouldn't see the
> > > event ".pc file added" which would trigger "must check overrides",
> > > I would just install an unsanitized .pc file => just leave it.
> >
> > I changed SUBST_NOOP_OK._pkgconfig to yes since this affects 9 of the
> > top 10 from the latest bulk build.  Because fixing the pkg-config files
> > is such a basic operation that is done so often, we will notice any bugs
> > in that general pattern quickly.
>
> I'm really, really annoyed by this attitude. We still have month old
> packages failing due to check-portability.mk inflating the already huge
> number of broken packages due to the OpenSSL fiasco. Can we please stop
> adding more unncessary breakage and get the numbers down into a sensible
> range for at least one mainstream platform? The current signal-to-noise
> ratio hides too many problems already.

While these "top 10" numbers may look large, they come from an
experimental bulk build that affects nobody but those who change
SUBST_NOOP_OK to its non-default value.  The whole purpose of that bulk
build is to find and fix the affected packages before they fail for a
standard pkgsrc build.

There is no additional breakage.  It's just the opposite.  Several
packages that built fine before but had silent bugs are now fixed.

I agree that having the stricter shell portability check generates more
packages that fail to build.  The point is that before, they succeeded
to build but under wrong assumptions.  I prefer to have binary packages
without these easy-to-detect bugs.

Roland