https://github.com/gustavo-iniguez-goya/opensnitch/issues/92
We don't really add init scripts for packages that aren't in the repos. You can always write a script yourself.
This is a reoccuring problem – packages from AUR that are written only for systemd. In my opinion the logical solution would be to add the runit, s6 and OpenRC init scripts to the AUR. A nice sideeffect is that runit, s6 and OpenRC would pierce into the mainline Arch :D
why should there be an AUR script for another init that archlinux does not use? it doesn't seem logical to me. Archlinux = systemd only. AUR = Archlinux :o 8) ;)
Create init script and with bit of luck it might just land in universe.
The Arch repo is systemd-only, the AUR isn't, since we do use the official AUR in Artix too – right? If you search for runit in the AUR, you will find out that the AUR already contains runit init scripts, specifically written for Artix (take a look at the corresponding PKGBUILD files): https://aur.archlinux.org/packages/?O=0&K=runit (https://aur.archlinux.org/packages/?O=0&K=runit)
Obviously it's not forbidden to upload non-systemd scripts to the AUR – so: why not?
(Besides that, I'm convinced that Arch won't stay systemd-only forever – but this is another topic.)
No. I don't think we have the right to flood AUR with our artixlinux programs / scripts. my personal opinion...
Regardless of that, I am convinced that we need a general solution for packages in the AUR that need additional runit/s6/OpenRC scripts on Artix. If not directly in the AUR then maybe in an official Artix repo where we can collect and supervise these scripts in a centralized manner.
Why not?
AUR is for all and not all packages can be added in normal repos, especially when there is licensing issue.
I actually think you aren't allowed to host source files on AUR so such script packages wouldn't be allowed there.
But they are already there:
* https://aur.archlinux.org/packages/?O=0&SeB=nd&K=-openrc (https://aur.archlinux.org/packages/?O=0&SeB=nd&K=-openrc)
* https://aur.archlinux.org/packages/?O=0&SeB=nd&K=runit (https://aur.archlinux.org/packages/?O=0&SeB=nd&K=runit)
* https://aur.archlinux.org/packages/?O=0&SeB=nd&K=-s6 (https://aur.archlinux.org/packages/?O=0&SeB=nd&K=-s6)
Scripts are allowed alone with PKGBUILDs
there is also chaotic aur (https://lonewolf.pedrohlc.com/chaotic-aur/) repo
Chaotic-aur is not like AUR.
AUR has PKBUILDS and scripts from users, while on Chaotic-aur, are binaries derived from AUR with automated builds.
placing system scripts in AUR is a bad idea... not only for security...
I think many AUR helpers might only look in the original AUR and any repos configured in pacman.conf which would make it more difficult to have a new AUR, putting things in an Artix repo would be easier from that perspective than in an alternative AUR.
In Pakku at least it seems hardcoded in with no currently existing mechanism for configuration:
const
aurUrl* = "https://aur.archlinux.org/"
Disagree
AUR is safe in this regard
security, than check the PKGBUILD and files provided to make the package, and also whole package after it was created.
Arch Linux AUR Repository Found to Contain Malware (https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/)
In this case opensnitch itself is in the AUR, so it's more about whether it's better to place init scripts for AUR packages in the AUR or in the repos. If there were init scripts for every AUR package that needed one for every init available it might make a lot of extra AUR packages, especially if different Arch based distros had different versions as well. But if there were only a few it wouldn't make a lot of difference either way. Or perhaps they could be bundled in an <initname>-aur-init-script package, hosted somewhere you could make a PR to add new ones, a tiny bit wasteful on drive space but nothing like firmware etc. If it installed them to some dir then you could probably symlink them to /etc/init.d or equivalent to save cluttering up your initscript dir and they would still get updates.
Another approach is a split package, suggested here for this problem:
https://bbs.archlinux.org/viewtopic.php?id=250693 (https://bbs.archlinux.org/viewtopic.php?id=250693)
What this has to do with our discussion about init scripts?
Plus is history..
Perhaps make the AUR package itself a split package. That would keep things together in a logical way yet not require extra PKGBUILD's that are possibly longer than the script they install. Some packages in the AUR already contain scripts in the source code which the PKGBUILD ignores, but it could be adapted to make those into sub-packages that could be installed independently. (Although the AUR Opensnitch PKGBUILD maintainer seems unwilling to support other inits.)
I totally agree! At Artix we do it always that way, so we should keep it that way. One PKGBUILD called "opensnitch" and three PKGBUILDs called "opensnitch-openrc", "opensnitch-runit" and "opensnitch-s6" for the init scripts.
That's not how a split package works though, you can have one PKGBUILD that makes more than one package, and only the ones you specified with <aurhelper> -S will get installed. Some AUR packages already do this, e.g.:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nim-git (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nim-git)
If you run <aurhelper> -S nim-git then nimble-git, nimsuggest-git, nimpretty-git get built but are simply deleted afterwards.
But say <aurhelper> -Ss nimble-git will still show it, as though they were individual packages.
So the opensnitch pkgbuild could have init scripts in individual packages for any init, the script itself would be located in either the AUR or the upstream source repo, but none of them would be installed unless the user wanted them. As the scripts don't need to be compiled and are just a few short files it wouldn't slow the build process. And they would be kept (and updated if required) alongside the package they refer to.
Hmm, I see two problems:
1.) Wouldn't this be very annoying for users of other distributions, who don't even know, what an init system is?
2.) In case the maintainer of the PKGBUILD is not from Artix, we won't be able to do that.
Wouldn't it be easier to add a separate PKGBUILD named opensnitch-s6-artix?
1) opensnitch-s6 is fine as a PKGBUILD name on AUR
2) why so?
1) No, why would it make any difference if you didn't install the extra initscript package? It wouldn't be in the original package. We install non-functional systemd service files from AUR packages. Many source bundles contain init scripts for a variety of inits, they are ignored by the build process, yet could be made available.
2) In case they are unhelpful you can't do that. I've had people from all manner of unexpected places help with Artix related issues, including those who work on projects alongside Lennart Poettering, when I asked nicely. But then you could try offering a patch to the PKGBUILD to make it easy for them (if you could figure one out of course ;D ) and if they don't accept, at least you can take them off your Xmas card list and save a stamp.
3) From my link to the Arch forum discussion:
Alad Wiki Admin/IRC Op/TU (who you may also frequently see in GitHub issue discussions, and I consider to be a reliable spokesperson for Arch Linux in general)
"Please don't create 20 PKGBUILDs for 20 services. If you insist on using 1 package per service, use a split package."
That's what Arch themselves recommend. If you want 1 package per service then put it in an Artix repo, which would also work. Probably that's the easiest but it would require a change in Artix policy regarding scripts for AUR packages. Or we could create the Artix User Repository and rewrite the aurhelpers to accomodate it, although there are lots in many different languages so probably only some would get done and it could take a while.
1) Do they build the packages from our AUR PKGBUILDS, put them in their repos as packages, and so they have problems with that?
2) Also, that thread on Arch forum mentions "this thread is about systemd and openrc coexisting on an archlinux installation WITH the base meta-package installed", so is completely irrelevant to building one service for User's usage imho (AUR is for users, iirc)
In the first post in this thread there's a suggested S6 init script from the opensnitch developer, so that could go somewhere when a location is decided on.
There are 2 opensnitch variants in the AUR, there's gustav-iniguez-goya and "opensnitch" which is a fork from evilsocket and "opensnitch-git" which has been in the AUR for longer. And there's another GitHub issue about this on evilsocket opensnitch-git:
https://github.com/evilsocket/opensnitch/issues/300 (https://github.com/evilsocket/opensnitch/issues/300)
The only example of openrc scripts in a split package I found in the AUR is this (although I didn't check everything):
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=openrc-accessible (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=openrc-accessible)
so it doesn't seem very common.
Just to add that in my experience, having multiple packages like the one in the quoted example is confusing to users. To users first switching to Artix, It is not obvious they need to install an additional package for their init system. Perhaps this needs to be more prominently displayed somewhere.
The s6 clearly defines for which init it is, so by adding a conflict to systemd in the PKGBUILD it will be clearly stipulated to all.
btw, what is your nick on AUR?
I have no account on AUR (yet).