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] Killing Python 2 (v2)
On 2/01/2020 17:24, Eli Schwartz via arch-dev-public wrote: > On 1/2/20 11:12 AM, Jelle van der Waa wrote: > >> # Remove python2 support >> >> * pycharm-community-edition - remove python2 support > > Seems reasonable to not encourage people to use python2 in an IDE these > days. > >> * vim - remove python2 support > > Are there any stats on vim ecosystem plugins which use the python2 > binding? Including non-packaged plugins? > You can safely remove python2 support from vim. The python2 support is only needed for vim plugins using python2, python2 can be perfectly linted by vim without python2-plugin support. *Most* plugins got forced to support both python2 and 3 when ubuntu default vim came without python2. So it should be fine and you can still install python2 from AUR or whatever to do the proper linting. signature.asc Description: OpenPGP digital signature
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
Re: [arch-dev-public] Killing Python 2 (v2)
On 01/02/20 at 11:18am, Santiago Torres-Arias via arch-dev-public wrote: > On Thu, Jan 02, 2020 at 05:12:33PM +0100, Jelle van der Waa wrote: > > > For packages still providing python2 functionality such as vim and > > others I propose we remove python2 support to actively to discourage > > people using it. > > I was +1 on this > > > # Remove python2 support > > > > * pycharm-community-edition - remove python2 support > > * vim - remove python2 support > > Until I saw this. > > I imagine editors and such may/could be an exception? So following up from what grazollini and Eli have said, I guess we can keep it for vim, maybe focus more on optdepends and actual makedepends for I've found a lot of gnome packages having a python2 makedepends which can be removed or moved to python 3. Felix brought up a more radical approach of removing check() for python2 modules which would allow a lot of python2 modules to be removed. This is also blocking him from updating packages since he needs to bring new python2 modules in to update some python/python2 modules iirc. Felix, can you enlighten us? I don't want you to be blocked from keeping Arch rolling =) Greetings, Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Killing Python 2 (v2)
On 01/02/20 at 07:09pm, keenerd via arch-dev-public wrote: > On 1/2/20, Jelle van der Waa wrote: > > * armagetronad - dead upstream, optional dep can be removed > > Fixed instead. It still works a treat. Thanks a lot! This was my hidden agenda all along ^_^ I've found many packages which have been building with Python 3 but simply weren't adjusted yet Thanks in advance, Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Killing Python 2 (v2)
Le jeu. 2 janv. 2020 à 17:12, Jelle van der Waa a écrit : > Hi All, > > 2020 happened and Python 2 is very much still alive, even worse there > will be an update in April. > > However we should actively strive to get rid of Python 2 before it. Some > upstreams are (still) working on porting to Python 3 such as Kodi, > inkscape, > mercurial and many more but for packages with dead upstreams and being > unrequired I propose we remove them. > > For packages still providing python2 functionality such as vim and > others I propose we remove python2 support to actively to discourage > people using it. > Texlive packages contain random Python scripts, a few of them might be ported to Python 3. As far as I know none of them is critical, I will simply remove the shebang rewriting in next packages and drop python2 from optdepends. I'll try to have a closer look to the ones accessible from PATH and actively remove them from /usr/bin if they are not ported. Rémy >
