Re: RFC - thoughts about Arch and init freedom?
Andreas Radke on Fri, 2022/12/16 22:46:
> 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. [...]
I remember these days, though I was a regular user back then. :)
The biggest argument again systemd is its complexity. Some people do prefer
simple init systems with init scripts.
Let's recap: Sure, systemd is complex, but it is well maintained (IMHO).
Generally it works well. The benefit is that systemd units can be written
quite easily, at least basic ones. Issues are easy to fix, things just work.
In contrast to that the complexity comes from the init scripts with the other
init systems. For each of them, again and again. Syntax errors, race
conditions, what ever.
And please note that systemd provides a lot of security features (limiting
privileges, presenting read-only filesystems, ...) for its services. It's
nearly impossible to implement this with init scripts, so system security
would drop a lot.
Just adding another init system to the repositories is the easy part.
Properly supporting it is anything between hard and impossible.
I think this would result in a huge amount of issue regarding broken or
missing init scripts, for all of us. (Well, at least anybody maintaining a
daemon of any kind.) I am not convinced this is a good idea. More the
opposite.
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}
pgpgxQboT7KGq.pgp
Description: OpenPGP digital signature
Re: Upcoming PHP 8.2 update and introduction of legacy packages
Hey, On 17/12/2022 11:13, Pierre Schmitz wrote: With the release to PHP 8.2 I will introduce a new set of packages to solve most of the issues with PHP updates. There are two valid requirements: On one hand people need the latest version to use its features or to develop new applications. And on the other hand users want to run third party applications that might not yet be compatible with the latest PHP runtime. I'll make the following changes to support both use cases while still keeping the rolling release model: In the end this would result in the following release schedule: php: currently 8.1 soon 8.2 December 2023: 8.3 php-legacy: currently: 8.1 December 2023: 8.2 (upstream provides security updates till December 2024; so we have some room to postpone when issues arise.) I don't object against providing an older PHP but why is it named php-legacy? We don't really have a policy for this, but it feels inconsistent versus the current php7, ruby2.7 package. (Ofcourse nodejs-lts-gallium is then also inconsistent but at least that is clearly named as that upstream). Greetings, Jelle
Re: Upcoming PHP 8.2 update and introduction of legacy packages
On Mon, Dec 19, 2022 at 3:40 PM Jelle van der Waa wrote: > I don't object against providing an older PHP but why is it named > php-legacy? We don't really have a policy for this, but it feels > inconsistent versus the current php7, ruby2.7 package. (Ofcourse > nodejs-lts-gallium is then also inconsistent but at least that is > clearly named as that upstream). I looked for several options regarding naming and ended up with either "-old" or "-legacy". I chose the later as it has a less negative tone and there are precedence for it in naming different releases branches. We also have similar concepts with libreoffice-still and libreoffice-fresh or nginx and nginx-mainline. Numbers couldn't be used here as both branches will get updated regularly. php-legacy will be bumped to version 8.2 and even 9.0 some day. So the difference is that I didn't want to provide a specific version but two different release branches. This makes it easier for users to update and packagers to maintain. It should be inline with Arch's rolling release model. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Re: RFC - thoughts about Arch and init freedom?
On Mon, Dec 19, 2022 at 8:01 AM Christian Hesse wrote: > Andreas Radke on Fri, 2022/12/16 22:46: > > 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. [...] > > I remember these days, though I was a regular user back then. :) > > The biggest argument again systemd is its complexity. Some people do prefer > simple init systems with init scripts. > > I agree. Wanting the most capable init system and wanting a more lightweight init system both sound like legitimate arguments. > Let's recap: Sure, systemd is complex, but it is well maintained (IMHO). > Generally it works well. The benefit is that systemd units can be written > quite easily, at least basic ones. Issues are easy to fix, things just > work. > In contrast to that the complexity comes from the init scripts with the > other > init systems. For each of them, again and again. Syntax errors, race > conditions, what ever. > > Many bugs of this type were filed in Flyspray. If we go back to having initscripts as the default (which no one is suggesting) they are sure to come back. The mere availability of another init system in the repos though will probably cause much less of a headache. There are versions of init freedom which would be too much work as people have rightly pointed out. So let me make a concrete proposal. 1. Put openrc in [community] which I have used on my laptop for two years without issue. 2. Make it depend on systemd (so it is clear we are not packaging eudev) and make installation print a warning that users of netctl and devtools will need to find alternatives. 3. Put openrc-arch-services in [community] as well, 4. Bugs for these two packages will be assigned to one of the three people who've expressed interest (Andreas, TJ and myself).
