[aur-general] Why keeping OpenRC related packages on AUR?
Hello. Note: posting in the right mailing list now. Oops! I hope it is the right place to discuss about this issue. I noticed there is a lot of OpenRC related packages on AUR. I don't want to start a flamewar, I just want to know what is going on with these PKGBUILDs. A quick search gave me 42 answers - some not related to this init system - 95% of them last updated between 2015 and 2018. https://aur.archlinux.org/packages/?O=0&K=openrc Is there any interest of keeping these PKGBUILDs? There is an official Archlinux + OpenRC init system called Artix, providing a migration guide from Arch or Manjaro. It is also listed in https://wiki.archlinux.org/index.php/Arch-based_distributions#Active "Artix Linux *2016, previously Arch-OpenRC" https://artixlinux.org/ https://wiki.artixlinux.org/Main/Migration By the way, it is written in the wiki that : "Warning: Arch Linux only has official support for systemd. When using OpenRC, please mention so in support requests." Source: https://wiki.archlinux.org/index.php/OpenRC Is there any explanations for keeping them? Thanks for your answers. -- Frederic Bezies fredbezies@gmail.com
On 9/16/19, fredbezies via aur-general
Hello.
Note: posting in the right mailing list now. Oops!
I hope it is the right place to discuss about this issue. I noticed there is a lot of OpenRC related packages on AUR. I don't want to start a flamewar, I just want to know what is going on with these PKGBUILDs.
A quick search gave me 42 answers - some not related to this init system - 95% of them last updated between 2015 and 2018.
https://aur.archlinux.org/packages/?O=0&K=openrc
Is there any interest of keeping these PKGBUILDs?
These packages all have maintainers and some of them have votes. So clearly there is.
There is an official Archlinux + OpenRC init system called Artix, providing a migration guide from Arch or Manjaro.
It is also listed in https://wiki.archlinux.org/index.php/Arch-based_distributions#Active
"Artix Linux *2016, previously Arch-OpenRC"
https://artixlinux.org/ https://wiki.artixlinux.org/Main/Migration
By the way, it is written in the wiki that : "Warning: Arch Linux only has official support for systemd. When using OpenRC, please mention so in support requests."
Making it easier to use things that are not officially supported is one of the purposes of the AUR.
Source: https://wiki.archlinux.org/index.php/OpenRC
Is there any explanations for keeping them?
Yes. The submission guidelines [1] clearly permit this type of package. Note that the AUR also has dpkg, rpm and several packages for ARM.
Thanks for your answers.
-- Frederic Bezies fredbezies@gmail.com
[1] https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Rules_of_subm...
On Mon, 16 Sep 2019 11:11:04 -0400, Connor Behan via aur-general wrote:
Note that the AUR also has dpkg, rpm and several packages for ARM.
I had the same thought :). Another example: "Support Arch Linux related mailing lists and other official Arch Linux support channels aren't an appropriate place to request help with snaps on Arch Linux. An appropriate place to ask for support is the Snapcraft forum." - https://wiki.archlinux.org/index.php/Snap#Support https://aur.archlinux.org/packages/snapcraft/ https://aur.archlinux.org/packages/snapd/ I suspect a lot of us dislike snappy, but it has got relatively many votes. You already pointed out, that this is what the AUR is for. Full ACK!
On Mon, 16 Sep 2019 16:38:11 +0200, fredbezies via aur-general wrote:
I hope it is the right place to discuss about this issue.
What issue...?
A quick search gave me 42 answers - some not related to this init system - 95% of them last updated between 2015 and 2018.
...are the PKGBUILDs broken? I'm using https://aur.archlinux.org/packages/ocz-ssd-utility/ , last time updated a year ago, 2018-08-26 18:29. It has got less votes than openrc and is way less popular. I've got 4 Toshiba SSDs and tomorrow I'll get another one, none of them is in the smartctl database. This software allows to get useful SMART information and to update the firmware while in use with an Arch install. # smartctl -i /dev/sdd | grep database Device is: Not in smartctl database [for details use: -P showall] Some software isn't useful for everybody. Some software does the jon, even if the last update is relatively old.
By the way, it is written in the wiki that : "Warning: Arch Linux only has official support for systemd. When using OpenRC, please mention so in support requests."
But Arch Linux is for advanced Linux users, some of them might build their own installs, maybe used as an embedded Linux. https://aur.archlinux.org/packages/?O=0&SeB=nd&K=arm&outdated=&SB=n&SO=a&PP=50&do_Search=Go Perhaps, ARM architecture related software should be removed, too? It's written that "Arch Linux (/ɑːrtʃ/) is a Linux distribution for computers based on x86-64 architectures." - https://en.wikipedia.org/wiki/Arch_Linux OpenRC isn't useful for you and me, but IMO, unless the PKGBUILDs aren't broken, but still maintained, it might be useful for some users.
On 9/16/19 10:38 AM, fredbezies via aur-general wrote:
Hello.
Note: posting in the right mailing list now. Oops!
I hope it is the right place to discuss about this issue. I noticed there is a lot of OpenRC related packages on AUR. I don't want to start a flamewar, I just want to know what is going on with these PKGBUILDs.
A quick search gave me 42 answers - some not related to this init system - 95% of them last updated between 2015 and 2018.
openrc-git and openrc-arch-services-git are, in fact, git packages, so it doesn't matter if they haven't been updated since 2015. openrc-sysvinit is hardly receiving daily updates, so likewise it's entirely reasonable to be an old package. Is it flagged out of date? No? I think we call that "stable software that works". :) Only two of the openrc-related packages are flagged out of date for any significant time. Feel free to request something be done about strongswan-nosystemd and docker-openrc-scripts-git.
Is there any interest of keeping these PKGBUILDs? There is an official Archlinux + OpenRC init system called Artix, providing a migration guide from Arch or Manjaro.
One of the core archlinux developers is the maintainer of openrc and openrc-sysvinit (and openrc-git). One assumes this is not against the rules. https://www.archlinux.org/people/developers/#andrew As for "interest", the AUR is not in the business of determining whether there is "interest" in a package. Our submission guidelines state that packages must be useful enough that other users *may* be interested in it, a criterion that is graded on good faith. Well, openrc is obviously useful enough for other distributions to base themselves on it, so it is clearly not software that is specific to one person that cannot be feasibly expected to be used by others.
It is also listed in https://wiki.archlinux.org/index.php/Arch-based_distributions#Active
"Artix Linux *2016, previously Arch-OpenRC"
https://artixlinux.org/ https://wiki.artixlinux.org/Main/Migration
Artix Linux may be based on Arch with openrc, but Manjaro Linux is based on Arch with systemd. Does that mean that it is forbidden for Arch users to use systemd, because it is also used by a derivative? No, that would be an extremely foolish idea. No one cares if another distribution uses something. We only care if Arch Linux could potentially use it. If so, it is useful. Arch Linux is a distribution that people make into what they want it to be. This stuff is definitely useful to at least some people. We will not play politics and tell people that they're not allowed to publicly experiment with different init systems -- we will simply refrain from pushing that into [core], and expect them to make a good-faith effort in the forums to alert people regarding their unique configurations.
By the way, it is written in the wiki that : "Warning: Arch Linux only has official support for systemd. When using OpenRC, please mention so in support requests."
Source: https://wiki.archlinux.org/index.php/OpenRC
Is there any explanations for keeping them?
Thanks for your answers.
So, the wiki explicitly clarifies that one is permitted to use openrc and if you do use openrc you are still eligible to receive help in the official support forums (as long as you let people know you are using it). The context of this is that if you install Arch Linux according to the Arch Way, then you are running Arch Linux... even if you later go ahead and install a custom kernel, or systemd-git. It is really no different if you go ahead and install linux-libre, openrc, and whatever other special interests packages you want to replace core system components. What matters is that you built up your system from Arch Linux, and any deviations from the official Arch Linux repositories are achieved by your own labor, which you understand. (Do not try to use this as an excuse to get support for Manjaro, Artix, or Parabola, you will get banned.) I am therefore unsure why you think we need an "explanation" for keeping them, as though it is some sort of dirty secret and we need to air the laundry and demand explanations from the "guilty parties" via some form of mob-with-pitchfork mentality. -- Eli Schwartz Bug Wrangler and Trusted User
Le lun. 16 sept. 2019 à 18:27, Eli Schwartz via aur-general
On 9/16/19 10:38 AM, fredbezies via aur-general wrote:
Hello.
Note: posting in the right mailing list now. Oops!
I hope it is the right place to discuss about this issue. I noticed there is a lot of OpenRC related packages on AUR. I don't want to start a flamewar, I just want to know what is going on with these PKGBUILDs.
A quick search gave me 42 answers - some not related to this init system - 95% of them last updated between 2015 and 2018.
Note: I forgot to set my options to receive every single message, so I'll be answering everybody here.
openrc-git and openrc-arch-services-git are, in fact, git packages, so it doesn't matter if they haven't been updated since 2015. openrc-sysvinit is hardly receiving daily updates, so likewise it's entirely reasonable to be an old package.
Ok. https://download.ghostbsd.org/releases/amd64/latest/GhostBSD19.09.iso
Is it flagged out of date? No? I think we call that "stable software that works". :)
Or could not, as these are git packages :D
Only two of the openrc-related packages are flagged out of date for any significant time. Feel free to request something be done about strongswan-nosystemd and docker-openrc-scripts-git.
Well, I was just looking at packages in AUR.
Is there any interest of keeping these PKGBUILDs? There is an official Archlinux + OpenRC init system called Artix, providing a migration guide from Arch or Manjaro.
One of the core archlinux developers is the maintainer of openrc and openrc-sysvinit (and openrc-git). One assumes this is not against the rules. https://www.archlinux.org/people/developers/#andrew
I did not know. I apologize.
As for "interest", the AUR is not in the business of determining whether there is "interest" in a package. Our submission guidelines state that packages must be useful enough that other users *may* be interested in it, a criterion that is graded on good faith. Well, openrc is obviously useful enough for other distributions to base themselves on it, so it is clearly not software that is specific to one person that cannot be feasibly expected to be used by others.
Ok. I just wanted to get such an explanation. Nothing more.
It is also listed in https://wiki.archlinux.org/index.php/Arch-based_distributions#Active
"Artix Linux *2016, previously Arch-OpenRC"
https://artixlinux.org/ https://wiki.artixlinux.org/Main/Migration
Artix Linux may be based on Arch with openrc, but Manjaro Linux is based on Arch with systemd. Does that mean that it is forbidden for Arch users to use systemd, because it is also used by a derivative? No, that would be an extremely foolish idea.
Indeed! I just remember some manjaro related packages to be deleted because they were using manjaro dependencies in some ways.
No one cares if another distribution uses something. We only care if Arch Linux could potentially use it. If so, it is useful.
Ok.
Arch Linux is a distribution that people make into what they want it to be. This stuff is definitely useful to at least some people. We will not play politics and tell people that they're not allowed to publicly experiment with different init systems -- we will simply refrain from pushing that into [core], and expect them to make a good-faith effort in the forums to alert people regarding their unique configurations.
Core access is restricted to developers only, if I'm right.
By the way, it is written in the wiki that : "Warning: Arch Linux only has official support for systemd. When using OpenRC, please mention so in support requests."
Source: https://wiki.archlinux.org/index.php/OpenRC
Is there any explanations for keeping them?
Thanks for your answers.
So, the wiki explicitly clarifies that one is permitted to use openrc and if you do use openrc you are still eligible to receive help in the official support forums (as long as you let people know you are using it).
Well, it is obvious.
The context of this is that if you install Arch Linux according to the Arch Way, then you are running Arch Linux... even if you later go ahead and install a custom kernel, or systemd-git. It is really no different if you go ahead and install linux-libre, openrc, and whatever other special interests packages you want to replace core system components.
Some projects are directly based on these technologies, providing their own repository. I thought it was simpler to use directly ISO from these projects.
What matters is that you built up your system from Arch Linux, and any deviations from the official Arch Linux repositories are achieved by your own labor, which you understand. (Do not try to use this as an excuse to get support for Manjaro, Artix, or Parabola, you will get banned.)
I won't ask any support for any of these distributions, even if I'm using one of them on my old laptop. I'm a 10 years long Archlinux user, who had known Archlinux 0.7x ISO... Good old /etc/rc.conf times... Or not!
I am therefore unsure why you think we need an "explanation" for keeping them, as though it is some sort of dirty secret and we need to air the laundry and demand explanations from the "guilty parties" via some form of mob-with-pitchfork mentality.
I just wanted to be sure why they were on AUR. Nothing less, nothing more. No tricky plans! Thanks a lot for your long answer.
-- Eli Schwartz Bug Wrangler and Trusted User
-- Frederic Bezies fredbezies@gmail.com
On 9/16/19 12:38 PM, fredbezies via aur-general wrote:
Indeed! I just remember some manjaro related packages to be deleted because they were using manjaro dependencies in some ways.
Well, if the package in question can only be run on Manjaro (or only makes sense to run on manjaro), then that is probably an issue. On the other hand, we encourage users of derivative distributions to contribute to the AUR as long as their contributions are also able to be used on Arch Linux. For example, https://aur.archlinux.org/packages/?K=manjaro These are mostly themes, but nothing says they cannot be used on Arch Linux too. And many AUR maintainers add archlinuxarm support for their packages (in fact, I do this for pacman-git myself) -- as long as it *also* compiles for x86_64, this is fine. Some parabola users historically maintained e.g. linux-libre -- this is fine too, Arch users can run this kernel if they want, it's a valid kernel...
Some projects are directly based on these technologies, providing their own repository. I thought it was simpler to use directly ISO from these projects.
But maybe someone wants to use those technologies with Arch. :)
What matters is that you built up your system from Arch Linux, and any deviations from the official Arch Linux repositories are achieved by your own labor, which you understand. (Do not try to use this as an excuse to get support for Manjaro, Artix, or Parabola, you will get banned.)
I won't ask any support for any of these distributions, even if I'm using one of them on my old laptop.
I'm a 10 years long Archlinux user, who had known Archlinux 0.7x ISO... Good old /etc/rc.conf times... Or not!
Then you are entitled to Arch Linux support for those Arch systems, regardless of which AUR packages you install on them (even the ones which bring back /etc/rc.conf). ;) -- Eli Schwartz Bug Wrangler and Trusted User
Le lun. 16 sept. 2019 à 18:57, Eli Schwartz via aur-general
On 9/16/19 12:38 PM, fredbezies via aur-general wrote:
Indeed! I just remember some manjaro related packages to be deleted because they were using manjaro dependencies in some ways.
Well, if the package in question can only be run on Manjaro (or only makes sense to run on manjaro), then that is probably an issue. On the other hand, we encourage users of derivative distributions to contribute to the AUR as long as their contributions are also able to be used on Arch Linux.
Sometimes AUR needs a little cleanup. But as long as added packages can be useful for every single Archlinux user... :D
For example, https://aur.archlinux.org/packages/?K=manjaro
These are mostly themes, but nothing says they cannot be used on Arch Linux too.
I noticed that. Even if some themes are... Well, ugly? :D Only one which doesn't look like a theme is this 2 years long outdated compiz port: https://aur.archlinux.org/packages/compiz-manjaro/
And many AUR maintainers add archlinuxarm support for their packages (in fact, I do this for pacman-git myself) -- as long as it *also* compiles for x86_64, this is fine.
Some parabola users historically maintained e.g. linux-libre -- this is fine too, Arch users can run this kernel if they want, it's a valid kernel...
If your hardware can run it, of course :D
Some projects are directly based on these technologies, providing their own repository. I thought it was simpler to use directly ISO from these projects.
But maybe someone wants to use those technologies with Arch. :)
If they want to make their lifes harder, why not? [...]
I'm a 10 years long Archlinux user, who had known Archlinux 0.7x ISO... Good old /etc/rc.conf times... Or not!
Then you are entitled to Arch Linux support for those Arch systems, regardless of which AUR packages you install on them (even the ones which bring back /etc/rc.conf). ;)
Well... I'm too used to systemd config files now :D
-- Eli Schwartz Bug Wrangler and Trusted User
-- Frederic Bezies fredbezies@gmail.com
participants (4)
-
Connor Behan
-
Eli Schwartz
-
fredbezies
-
Ralf Mardorf