[arch-dev-public] Adding a "posix" metapackage
After a bit of research work and making sure one or two things have been
properly packaged, I've developed a PKGBUILD which ensures that a system
has the POSIX shell and utilities (XCU) section installed. I believe
this is an interesting thing to track, and people will want to know they
have it installed... in aid of this, I've gotten two major holdouts
packaged a while back -- pax (thanks to dbermond) and ncompress.
I'd like to add this package to community, although given it's never
been in the AUR before, it's never had AUR votes...
One of the advantages of having this metapackage is that someone can,
while installing arch, `pacman -S posix-user-portability` and get
essentially everything one would expect to have available on a unix-like
platform, most notably, the interesting parts of the base group that no
longer have an equivalent. i.e. man-db, vi, patch, diffutils, ed.
I've only included XCU for now, because the system interfaces and
headers are a bit out of scope for me to package and replace in the
event that they'd be missing anything... and also because I'm mainly
interested in the POSIX toolset itself. That being said, I'd certainly
be open to suggested improvements, should anyone have recommendations
for expanding the scope.
Thoughts?
For reference, here is my PKGBUILD: https://paste.xinu.at/m-XoggqFGE/
And reproduced here:
# Maintainer: Eli Schwartz
On 1/3/20 5:35 AM, Eli Schwartz via arch-dev-public wrote:
After a bit of research work and making sure one or two things have been properly packaged, I've developed a PKGBUILD which ensures that a system has the POSIX shell and utilities (XCU) section installed. I believe this is an interesting thing to track, and people will want to know they have it installed... in aid of this, I've gotten two major holdouts packaged a while back -- pax (thanks to dbermond) and ncompress.
I'd like to add this package to community, although given it's never been in the AUR before, it's never had AUR votes...
One of the advantages of having this metapackage is that someone can, while installing arch, `pacman -S posix-user-portability` and get essentially everything one would expect to have available on a unix-like platform, most notably, the interesting parts of the base group that no longer have an equivalent. i.e. man-db, vi, patch, diffutils, ed.
I've only included XCU for now, because the system interfaces and headers are a bit out of scope for me to package and replace in the event that they'd be missing anything... and also because I'm mainly interested in the POSIX toolset itself. That being said, I'd certainly be open to suggested improvements, should anyone have recommendations for expanding the scope.
Thoughts?
I think it's a great idea, i definitely see myself using posix{,-user-portability} once it becomes available. -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Fri, Jan 03, 2020 at 03:49:11PM +0100, Robin Broda via arch-dev-public wrote:
On 1/3/20 5:35 AM, Eli Schwartz via arch-dev-public wrote:
After a bit of research work and making sure one or two things have been properly packaged, I've developed a PKGBUILD which ensures that a system has the POSIX shell and utilities (XCU) section installed. I believe this is an interesting thing to track, and people will want to know they have it installed... in aid of this, I've gotten two major holdouts packaged a while back -- pax (thanks to dbermond) and ncompress.
I'd like to add this package to community, although given it's never been in the AUR before, it's never had AUR votes...
One of the advantages of having this metapackage is that someone can, while installing arch, `pacman -S posix-user-portability` and get essentially everything one would expect to have available on a unix-like platform, most notably, the interesting parts of the base group that no longer have an equivalent. i.e. man-db, vi, patch, diffutils, ed.
I've only included XCU for now, because the system interfaces and headers are a bit out of scope for me to package and replace in the event that they'd be missing anything... and also because I'm mainly interested in the POSIX toolset itself. That being said, I'd certainly be open to suggested improvements, should anyone have recommendations for expanding the scope.
Thoughts?
I think it's a great idea, i definitely see myself using posix{,-user-portability} once it becomes available.
+1 to this. I definitely think this would be useful to have when needed. I'm curious, though, are there any specifics about the providers on these POSIX tools/libraries/whatnot (i.e., would it be wortwhile discussing the alternatives?). Cheers! -Santiago
On 1/3/20 10:22 AM, Santiago Torres-Arias via arch-dev-public wrote:
On Fri, Jan 03, 2020 at 03:49:11PM +0100, Robin Broda via arch-dev-public wrote:
On 1/3/20 5:35 AM, Eli Schwartz via arch-dev-public wrote:
After a bit of research work and making sure one or two things have been properly packaged, I've developed a PKGBUILD which ensures that a system has the POSIX shell and utilities (XCU) section installed. I believe this is an interesting thing to track, and people will want to know they have it installed... in aid of this, I've gotten two major holdouts packaged a while back -- pax (thanks to dbermond) and ncompress.
I'd like to add this package to community, although given it's never been in the AUR before, it's never had AUR votes...
One of the advantages of having this metapackage is that someone can, while installing arch, `pacman -S posix-user-portability` and get essentially everything one would expect to have available on a unix-like platform, most notably, the interesting parts of the base group that no longer have an equivalent. i.e. man-db, vi, patch, diffutils, ed.
I've only included XCU for now, because the system interfaces and headers are a bit out of scope for me to package and replace in the event that they'd be missing anything... and also because I'm mainly interested in the POSIX toolset itself. That being said, I'd certainly be open to suggested improvements, should anyone have recommendations for expanding the scope.
Thoughts?
I think it's a great idea, i definitely see myself using posix{,-user-portability} once it becomes available.
+1 to this. I definitely think this would be useful to have when needed. I'm curious, though, are there any specifics about the providers on these POSIX tools/libraries/whatnot (i.e., would it be wortwhile discussing the alternatives?).
Depends on the alternative. I think the most logical way to do providers would be via https://wiki.archlinux.org/index.php/User:Allan/Alternatives Currently, the repos do things like have cronie and fcron available, but if you actually want crontab you need to install the former -- the latter doesn't provide the POSIX tool, it provides "fcrontab" which is the wrong name. So it's not eligible *today* to meet the requirements. -- Eli Schwartz Bug Wrangler and Trusted User
On Thu, 2020-01-02 at 23:35 -0500, Eli Schwartz via arch-dev-public wrote:
...
Thoughts?
Posix is an old standard which fail to make a common ground to Unix systems. If we think user needs meta packages to install their Arch, is the Linux Standard Base more relevant to us? Cheers, Sébastien "Seblu" Luttringer
On 1/3/20 10:48 AM, Sébastien Luttringer wrote:
On Thu, 2020-01-02 at 23:35 -0500, Eli Schwartz via arch-dev-public wrote:
...
Thoughts?
Posix is an old standard which fail to make a common ground to Unix systems.
If we think user needs meta packages to install their Arch, is the Linux Standard Base more relevant to us?
I would argue that POSIX is a standard which people actually care about, and LSB is a standard which no one cares about. POSIX defines minimally supported featuresets, LSB defines binary compatibility ABIs. Also, requirements like "must be able to install software in the rpm format" don't actually provide value IMO. But at the end of the day, if someone wanted to work on LSB compliance in Arch Linux, I'd be personally okay with that. I just won't work on it myself. -- Eli Schwartz Bug Wrangler and Trusted User
On Fri, 2020-01-03 at 11:11 -0500, Eli Schwartz via arch-dev-public wrote:
On 1/3/20 10:48 AM, Sébastien Luttringer wrote:
On Thu, 2020-01-02 at 23:35 -0500, Eli Schwartz via arch-dev-public wrote:
...
Thoughts?
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 POSIX. 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)? The GNU Operating System (our core rely on it) have disagreements with POSIX and are de-facto non-POSIX (e.g df). 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? 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. Cheers, Sébastien "Seblu" Luttringer
On 4/1/20 12:47 pm, Sébastien Luttringer via arch-dev-public wrote:
One unfortunate consequence could be to have packages rely on it to make dependencies shorter, and make us pull cups or cronie.
What?! That is like saying one unfortunate consequence of pamcan hooks is that packages can have no files and just download and compile the source in a hook. It is a ridiculous consideration. A
On Sat, 2020-01-04 at 13:08 +1000, Allan McRae via arch-dev-public wrote:
On 4/1/20 12:47 pm, Sébastien Luttringer via arch-dev-public wrote:
One unfortunate consequence could be to have packages rely on it to make dependencies shorter, and make us pull cups or cronie.
What?! That is like saying one unfortunate consequence of pamcan hooks is that packages can have no files and just download and compile the source in a hook. It is a ridiculous consideration.
Your extreme example seems, indeed, a ridiculous use of hooks. I hadn't realized that adding posix as a dependency on a package will be as extreme and ridiculous as the example that you have just gave. My mistake. Regards, Sébastien "Seblu" Luttringer
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 POSIX.
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 metapackage). 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
On 1/2/20 11:35 PM, Eli Schwartz wrote:
After a bit of research work and making sure one or two things have been properly packaged, I've developed a PKGBUILD which ensures that a system has the POSIX shell and utilities (XCU) section installed. I believe this is an interesting thing to track, and people will want to know they have it installed... in aid of this, I've gotten two major holdouts packaged a while back -- pax (thanks to dbermond) and ncompress.
I'd like to add this package to community, although given it's never been in the AUR before, it's never had AUR votes...
As there do not seem to be any objections, I've uploaded this now. https://www.archlinux.org/packages/community/any/posix/ -- Eli Schwartz Bug Wrangler and Trusted User
participants (5)
-
Allan McRae
-
Eli Schwartz
-
Robin Broda
-
Santiago Torres-Arias
-
Sébastien Luttringer