Re: How to check installed binaries using the same tests in the source code?

[Santiago Vila]

El 14/1/25 a las 19:22, Bruno Haible escribió:
> > > (A) For packages that install independent programs, like coreutils
> > >       or diffutils, the most frequent types of installation bugs are:
> > >         - program not installed or installed in wrong location,
> > >         - shared libraries that are needed by the programs are not
> > >           not installed or installed in a location not listed in RPATH.
> > >       The Automake-generated default 'installcheck', that — as you say —
> > >       invokes all programs with --version and --help is a good and fast
> > >       test against these installation bugs.
> >
> > I would say that it's even most frequent that some program produces
> > a different output than the expected.
>
> Why? If the executable is simply copied from the builddir to $PREFIX/bin,
> what can go wrong?

Hmm, sorry, maybe we are using a different name for the same thing, or the same
name for different things.

The name "installcheck" suggests a check which checks that the program
is "correctly installed". If we check --version and --help for all the programs
that are supposed to be installed, that would certainly checks almost everything
that we want to check for that particular purpose (i.e. "correctly installed")

But Debian source packages are already created in such a way that the above
is very difficult to happen. During the build, the program is typically
installed (by "make install") into a temporary directory debian/tmp,
and from this place the different binary packages are populated.

If something installed in debian/tmp is not used in any binary package,
the dh_missing tool will exit with error and the package build will fail.

If we call that "installation bugs", they are difficult to happen considering
what we already do.

What I was suggesting was to extend the (what I think it's the traditional) 
meaning
of "make installcheck" so that it does "the same" thing "make check" is already 
doing.

Then we could catch changes in actual behavior, for example, the recent
libunistring change that made output from msgmerge to be slightly different.

Thanks.