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
