Re: [Groff] new automake system

[Ingo Schwarze]

Hi Ralph,

Ralph Corderoy wrote on Tue, Sep 23, 2014 at 11:17:28AM +0100:
> Ingo Schwarze wrote:

>>  - it prefers /usr/local/bin/gsed over /usr/bin/sed
>> 
>>  - it prefers /usr/local/bin/bison over /usr/bin/yacc
>> 
>> Prefering the GNU versions over the native POSIX versions is bad
>> because it causes needless build dependencies.

> If both are available, and the code that uses them is compatible with
> either, why does it matter if the GNU version is used?  It may be it's
> faster, or gives better errors during development over, say, an ancient
> yacc.  I don't see it's a build dependency if it's happy using the
> non-GNU versions when they are the only ones available.

More than one reason, actually.

For end-users, it compromises predictable, repeatable builds.
A build shouldn't use anything except what it explicitly depends
on, and the build result should not be different depending on whether
or not some unrelated software is installed.  And how can *we* know
whether there is some system out there where this introduces subtle
differences?  Unless the differences cause considerable functional
defects, they are not likely to ever get reported.

For user-maintainer communication, imagine that a user reports some
problem to a port/package maintainer.  The maintainer fails to
reproduce.  After much back an forth, it turns out the user had,
say, gsed(1) installed on the machine, which the maintainer did not
have while building.  For that to cause grief, it's not even required
that gsed(1) *causes* the problem, it is sufficient that gsed(1)
changes the way in which the problem manifests itself.

For porters and packagers, the problem is that they may have
gsed(1) installed when developing the port, and things just work.
Maybe they miss the hidden dependency, and when later try to build
it without gsed(1), it may break.  Maybe they notice the fact that
gsed(1) is picked up.  Then what should they do?  The best option
probably is to uninstall gsed(1), check that everything still works,
finish the port, then reinstall gsed(1) if they need it again, later.
Detecting this and retesting everything after detecting and removing
the fake dependency is a considerable amount of additional hassle.

For bulk build machines, the aspect of predictable builds is even
considerably worse than for end-users.  Unless something is explicitly
marked as a dependency or as conflicting, in a bulk build, you
typically can neither guarantee that it is installed nor that it
is not installed at build time.  So you end up with randomly changing
packages in official, OS-supplied package repositories which can
have all kinds of ill effects.

I'm not even sure this list of potential issues is complete.

Yours,
  Ingo