Re: [arch-dev-public] Adding a "posix" metapackage
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 signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Adding a "posix" metapackage
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 signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Adding a "posix" metapackage
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 signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Adding a "posix" metapackage
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
Re: [arch-dev-public] Adding a "posix" metapackage
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 signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Adding a "posix" metapackage
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 signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Adding a "posix" metapackage
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
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] Adding a "posix" metapackage
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 signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] Adding a "posix" metapackage
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
signature.asc
Description: PGP signature
Re: [arch-dev-public] Adding a "posix" metapackage
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
signature.asc
Description: OpenPGP digital signature
