Removing the imap,c-client and php-imap packages
While preparing updates to our PHP packages I think it's now time to retire the abandoned imap package: https://archlinux.org/packages/extra/x86_64/imap/ The last upstream version was from 2007 and the upstream website is gone for many years now. I doubt anyone actually uses the imap server; its main use is probably to compile the php-imap extension (which also might get removed by upstream in the future). Redhat and Fedora removed the library last year. Therefore I'd like to remove imap, c-client and php-imap. php-imap is currently optionally required by nextcloud and postfixadmin; likely to authenticate against a third party IMAP server. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
RFC - thoughts about Arch and init freedom?
The older Arch developers may remember vaguely how Arch has introduced [1] and migrated to systemd [2] becoming the new and only supported init system. Back in these days we had some developers in our team being part of upstream systemd developers. Not much discussion happened about supporting any alternative init system. Other alternative init systems have become niche in Arch and faded out over time. Nowadays systemd has become much more than a plain init system and plans to grow further. This may leadd to problems from a user and system administrator perspective once you are hit by some bug. Systemd as a whole thing doesn't care about the Unix philosophy to do only one thing but well. Many and often highly skilled users left and leave Arch therefor or choose some different distribution or an Arch fork because there's no init choice in Arch Linux. I suggest to fix this lack of init choice/alternative. I'd like to implement it into the official Arch Linux repos allowing to choose some different init replacement. We can either just add a 2nd init system in the most simple way or allow real init-freedom[3] offering full choice and leave it up to be further filled by the community. Arch Linux could take advantage of this bringing back some lost parts of the community. With more choice and better portability Arch could become a better base for porting to new architectures. And freedom and alternatives is always good in the open source world. The clear drawback would become some added complexity allowing to choose either systemd or its replacement parts and to make all of them to work with existing packages especially daemon services. I'm willing to do most of the packaging implementations when a majority of the team think it's good idea and worth the effort. It's a rather huge effort and imho not a task for some personal custom repo as it may affect devtools, infrastructure and maybe more of our core distro. If you want to check how some init choice can be implemented I suggest to start looking at Parabola[4], Hyperbola[5] and [6] Artix Linux forks first. These are all rather small projects but we being the mother and true Arch community should have the resources to implement it in a proper way without any major drawbacks. PS: Please leave out all emotions about hating or loving systemd. I'm trying to do so as well. -Andy [1]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/3JTBCAIKC7IELB6LMSEIS66E773OSKL5/ [2]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/EK553KWVOY6UYBDSKAP5XQIPGHNLJXMH/ [3]https://www.devuan.org/os/init-freedom [4]https://wiki.parabola.nu/Repositories#nonsystemd [5]https://wiki.hyperbola.info/doku.php?id=en:philosophy:systemd_denial [6]https://wiki.artixlinux.org/Main/Installation [6] pgpGEblJ9JUts.pgp Description: Digitale Signatur von OpenPGP
Re: RFC - thoughts about Arch and init freedom?
On Fri, Dec 16, 2022 at 10:46 PM Andreas Radke wrote: > > The older Arch developers may remember vaguely how Arch has introduced > [1] and migrated to systemd [2] becoming the new and only supported init > system. Back in these days we had some developers in our team being part > of upstream systemd developers. Not much discussion happened about > supporting any alternative init system. Other alternative init systems > have become niche in Arch and faded out over time. > > Nowadays systemd has become much more than a plain init system > and plans to grow further. This may leadd to problems from a user and > system administrator perspective once you are hit by some bug. Systemd > as a whole thing doesn't care about the Unix philosophy to do only one > thing but well. > > Many and often highly skilled users left and leave Arch therefor or > choose some different distribution or an Arch fork because there's no > init choice in Arch Linux. > > I suggest to fix this lack of init choice/alternative. I'd like to > implement it into the official Arch Linux repos allowing to choose > some different init replacement. We can either just add a 2nd init > system in the most simple way or allow real init-freedom[3] offering > full choice and leave it up to be further filled by the community. > > Arch Linux could take advantage of this bringing back some lost parts > of the community. With more choice and better portability Arch could > become a better base for porting to new architectures. And freedom and > alternatives is always good in the open source world. The clear > drawback would become some added complexity allowing to choose either > systemd or its replacement parts and to make all of them to work with > existing packages especially daemon services. > > I'm willing to do most of the packaging implementations when a majority > of the team think it's good idea and worth the effort. It's a rather > huge effort and imho not a task for some personal custom repo as it may > affect devtools, infrastructure and maybe more of our core distro. > > If you want to check how some init choice can be implemented I suggest > to start looking at Parabola[4], Hyperbola[5] and [6] Artix Linux forks > first. These are all rather small projects but we being the mother and > true Arch community should have the resources to implement it in a > proper way without any major drawbacks. > > PS: Please leave out all emotions about hating or loving systemd. I'm > trying to do so as well. > > -Andy Hi, I was a Trusted User when we migrated to systemd and I think it's the good choice... Right now, we have lots of packages that depends, directly or indirectly, on systemd (for example udev or gnome) and, often, if you want to support a non-systemd system you need to re-build the package with different configure options (or to apply some unofficial patch in some cases) and this is, I think, against, the concept of KISS ArchLinux always had. Moreover, does it means the package maintainer should also write the init files for the packages that only ship systemd service files? Just my 2 cents. > [1]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/3JTBCAIKC7IELB6LMSEIS66E773OSKL5/ > [2]https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/EK553KWVOY6UYBDSKAP5XQIPGHNLJXMH/ > [3]https://www.devuan.org/os/init-freedom > [4]https://wiki.parabola.nu/Repositories#nonsystemd > [5]https://wiki.hyperbola.info/doku.php?id=en:philosophy:systemd_denial > [6]https://wiki.artixlinux.org/Main/Installation > > [6]
Re: RFC - thoughts about Arch and init freedom?
On Fri, Dec 16, 2022 at 10:46:12PM +0100, Andreas Radke wrote: > The older Arch developers may remember vaguely how Arch has introduced > [1] and migrated to systemd [2] becoming the new and only supported init > system. Back in these days we had some developers in our team being part > of upstream systemd developers. Not much discussion happened about > supporting any alternative init system. Other alternative init systems > have become niche in Arch and faded out over time. Arch never had support for more than one init, and implementing this support would be a new feature. The BSD-style init stuff is still in a repository managed by Tom for those curious about this historical thing. https://github.com/teg/initscripts-arch > Nowadays systemd has become much more than a plain init system > and plans to grow further. This may leadd to problems from a user and > system administrator perspective once you are hit by some bug. Systemd > as a whole thing doesn't care about the Unix philosophy to do only one > thing but well. This is a faux argument. "unix philosophy" is a principle used for the core unix tooling and was never intended as a guiding principle in software development. How this is an argument against systemd is beyond me and mostly recycled garbage from the anti-systemd crowd. > Many and often highly skilled users left and leave Arch therefor or > choose some different distribution or an Arch fork because there's no > init choice in Arch Linux. Who are these people? > I suggest to fix this lack of init choice/alternative. I'd like to > implement it into the official Arch Linux repos allowing to choose > some different init replacement. We can either just add a 2nd init > system in the most simple way or allow real init-freedom[3] offering > full choice and leave it up to be further filled by the community. > > Arch Linux could take advantage of this bringing back some lost parts > of the community. With more choice and better portability Arch could > become a better base for porting to new architectures. And freedom and > alternatives is always good in the open source world. The clear > drawback would become some added complexity allowing to choose either > systemd or its replacement parts and to make all of them to work with > existing packages especially daemon services. > > I'm willing to do most of the packaging implementations when a majority > of the team think it's good idea and worth the effort. It's a rather > huge effort and imho not a task for some personal custom repo as it may > affect devtools, infrastructure and maybe more of our core distro. Whats the goal? Feature parity with the existing packages? Would we need to seek solutions to common problems solved by systemd which is not solved by other init systems? Would "choosing another init" imply that the systemd library shouldn't be installed on the system? The level of complexity and demands depends widely on how you would like to implement this support. And there is not enough information here to judge that accurately. > If you want to check how some init choice can be implemented I suggest > to start looking at Parabola[4], Hyperbola[5] and [6] Artix Linux forks > first. These are all rather small projects but we being the mother and > true Arch community should have the resources to implement it in a > proper way without any major drawbacks. Artix blindly copies their init-scripts from other distributions like Void, Gentoo and Alpine. They are not a reliable source of any information. (They have also started blindly copying over our package sources and remove attribute along with it which has left me with a very bad taste for the maintainers.) Hyperbola I have no opinions and Parabola has largely been nice people to work with. > PS: Please leave out all emotions about hating or loving systemd. I'm > trying to do so as well. It would help if you didn't recite poor arguments from a lot of the anti-systemd crowd though... tl;dr: Generally my opinion on this is lukewarm, the effort can't be worth it unless there is an explicit plan on what "init-freedom" actually entails and how you actually intend to support it. We can't even properly support multiple architectures, and I find it hard to believe we can support multiple inits. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: RFC - thoughts about Arch and init freedom?
> Nowadays systemd has become much more than a plain init system > and plans to grow further. This may leadd to problems from a user and > system administrator perspective once you are hit by some bug. Systemd > as a whole thing doesn't care about the Unix philosophy to do only one > thing but well. That's unfortunately quite common in the Linux space now, but systemd is for sure the worst offender. > Many and often highly skilled users left and leave Arch therefor or > choose some different distribution or an Arch fork because there's no > init choice in Arch Linux. Whenever I've pitched Arch to users of other Linuxes or BSDs, the main (or only) complaint is often that it's "a systemd distro." Then Artix gets brought up and promptly rejected for being a much smaller project with fewer developers and users, making it less appealing for anything but casual/hobbyist use. Having a supported alternative on proper Arch would make a lot of people happy. I'd be very supportive of exploring this possibility from both a security perspective and to promote freedom of choice, but I expect you'll get much more pushback and complaining than support...
