[arch-dev-public] Adding a "posix" metapackage

Eli Schwartz eschwartz at archlinux.org
Sun Jan 5 00:15:24 UTC 2020

On 1/3/20 9:47 PM, Sébastien Luttringer wrote:
>> I would argue that POSIX is a standard which people actually care about,
>> and LSB is a standard which no one cares about.
> I agree that few people are interested in LSB. I think it's barely the same for
> Our scripts are not written POSIX compatible (i.e they rely on more tools than
> the standard). Do you still know people writing POSIX compatible scripts
> nowadays (students excluded)?

Lots of people? Anyone who works with non-Linux variants of Unix. There
are many such people.

> The GNU Operating System (our core rely on it) have disagreements with POSIX
> and are de-facto non-POSIX (e.g df).

The GNU coreutils and other GNU projects are mostly POSIX compatible,
and in the uncommon cases where they deviate from POSIX, they have
carefully thought out rationales.

Furthermore, even in those cases, they take great pains to *still* be
POSIX compatible, if you export the environment variable "POSIXLY_CORRECT".

In the case of df, I believe the only deviation from POSIX is in the
default block size (POSIX says 512 bytes, and POSIXLY_CORRECT will
ensure this is so, but it may otherwise default to 1024).

> I'm not able to tell you something in Arch that rely on POSIX.2 (Shell and
> Utilities).
> What make you think people care about this standard?

As Ralph Corderoy has mentioned on arch-general, Arch users may be
writing scripts that also target non-Linux platforms, or use scripts
which are authored by people on non-Linux platforms. This will probably
tend to be more noticeable in areas where BSD, or commercial UNIX, has a
stronger presence than in the desktop sector.

On a personal level, my scripts feel comfortable assuming certain POSIX
required utilities exist, like "cmp" (which is notably not installed by
default on archlinux, ever since the move of base from a group to a

And POSIX doesn't say you cannot rely on non-POSIX tools -- it just says
you can rely on the POSIX ones existing, and having certain behavior. I
have certainly never gone out of my way to document that a script relies
on the "cp" command existing, whereas I would probably document its
reliance on "wget"...

> I'm not opposed to add a posix metapackage. I'm just very reserved about its
> usefulness.
> One unfortunate consequence could be to have packages rely on it to make
> dependencies shorter, and make us pull cups or cronie.

The posix metapackage shall not be (mis)used in such a manner, please
report a bug if anyone does so. It is not the business of a package
dependency list to rely on "POSIX", it is the business of a package list
to rely on archlinux's mandatory base and otherwise specify its own
requirements without forcing a POSIX conformity the user never asked for.

It shall be used to help individuals ensure their system is a suitable
platform for running a POSIX userland, for example, to know that
thirdparty ISV scripts will work or that they may rely on certain
interactive commands existing on an offline system (vi, if the user
portability option is selected).

Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20200104/c42bffc1/attachment.sig>

More information about the arch-dev-public mailing list