On Mon, 25 Mar 2019 at 06:34, Japheth Cleaver <cleaver(a)terabithia.org> wrote:
On 3/25/2019 2:46 AM, Nicolas Mailhot wrote:
> Le 2019-03-25 09:53, Jan Pokorný a écrit :
>
>> Good point, and that's something capable of making upstream
>> maintenance cumbersome at times (sed is a common pet peeve),
>> but that's an order of magnitude more demanding level when it
>> comes to portability, and with Fedora settled firmly just around
>> GNU approaches and extensions, there's hardly a pressing need for
>> the spec files to come anywhere close (but if so, the restrictions
>> should not be limited to shell interpreter alone as remarked,
>> since POSIX compliance is a wider topic).
>
> More accurately, what is the point of wasting energy on making a Linux
> system POSIX-only today? POSIX was a useful tool to make proprietary
> unixes more or less compatible with one another. The situation has
> changed since. Linux has taken over most of the marketplace. That
> means the common compat layer you need to target to replace it with
> something else, is whatever major Linux distributions agree on, and
> that includes all the GNU tools with all their non-POSIX extensions.
The original point was on the execution shell, not external commands
being run through it. Those can always vary according to the needs of
the .spec writer, which is why Requires(pre/post) exist. (Using perl's
broader compatibility to get around sed oddities springs to mind.) It's
true that it's always good to strive for maximal compatibility whenever
possible, but that's slightly orthogonal here.
It's clear that there are GNU/Linux systems that do simply use other
Bourne shells by default, and users who would like to do so
individually. Removing unnecessary bashisms would be very nice, but a
sensible, coherent specification would at least be a good start.
Try 1 at specification:
Fedora is based on GNU tools versus strict POSIX compliant ones. As
such, packagers can expect that /bin/sh is /bin/bash, /bin/awk is
/bin/gawk, /bin/cc is /bin/gcc ad naseum. This means that unless
specified elsewhere that a 'bashism', 'gawkism', 'gcc-ism' is not
to
be used, packagers may rely on tools to act as the upstream GNU tools
in their spec files.
--
Stephen J Smoogen.