Suggestions_for_services.md: Change in the development branch.

[mobinmob]

This changed is prompted by three reasons:

• A seperate branch is confusing for first time contributors.
• Some files need to be updated in the master branch either way (conf/void-66-conf.md)
• It is easy to judge the project by the activity that appears only on the master branch...

Please leave comments on this PR if there is a reason to keep the current scheme - or more reasons to change it. @flexibeast @teldra @paper42 @linuxergr @Obarun

After the change I will promptly merge this to devel and devel to master. I will leave this open until 20220206.

[linuxergr]

Pretty understanding Void's cores devs policy regarding new daemons/packages, nevetheless I need to script a proved working bunch of services that their daemons may never get approved by Void, such as Webmin e.t.c., so I consider a way has to be found in this regard, as already did with earlyoom and ananicy. Tired on having such delays, but always on the job! Cheers!

[mobinmob]

Pretty understanding void's cores devs policy regarding new daemons/packages, nevetheless I need to script a proved working bunch of services that their daemons may never get approved by Void, such as Webmin e.t.c., so I consider a way has to be found in this regard, as already did with earlyoom and ananicy. Tired on having such delays, but always on the job! Cheers!

I have not considered what will happen with frontend service files for sw that is not packaged (yet) in void-packages. Ι have no problem having them in the master branch. The worst that can happen is someone enabling a frontend for a non-existent daemon. which is annoying but not the end of the world. If there is another issue I can fix it in the templates and exclude these frontends from packaging. Does that seem like an acceptable solution? I have utlogd in the PRs which is also not in the void-packages repo.

[linuxergr]

I have not considered what will happen with frontend service files for sw that is not packaged (yet) in void-packages. Ι have no problem having them in the master branch. The worst that can happen is someone enabling a frontend for a non-existent daemon. which is annoying but not the end of the world. If there is another issue I can fix it in the templates and exclude these frontents from packaging. Does that seem like an acceptable solution? I have utlogd in the PRs which is also not in the void-packages repo.

I am ok @mobinmob with this approach, thanks :) However, more flexibility should perhaps be appllied by their side, when new valuable toys arrive in the distro, just noting that down again.

Appreciate!

[paper42]

With the ananicy PR, multiple comments were raised, some of them did get fixed, some didn't, some got fixed, but then got reverted. The PR contains 3 commits including merge commits and for some reason touches earlyoom even though it's supposed to be only about ananicy. It's not in a mergeable state. The ball has been on your side for 4 months @linuxergr.

In my opinion (which is not important since I don't own this repository), it should only contain services for void packages, not for things void might have as a package one day.

[mobinmob]

In my opinion (which is not important since I don't own this repository), it should only contain services for void packages, not for things void might have as a package one day.

In the README I point to the templates provided under packaging/ as the preffered method of installation. That is why I mentioned excluding some frontend service files from the resulting package - the difference between the repo contents and the package in that case should probably be explained in the README.

I understand your point about having only services for sw that exists in the voidlinux repos - that is my objective. But I do not like rejecting frontends that work and represent work on the part of a contributor :)

[linuxergr]

With the ananicy PR, multiple comments were raised, some of them did get fixed, some didn't, some got fixed, but then got reverted. The PR contains 3 commits including merge commits and for some reason touches earlyoom even though it's supposed to be only about ananicy. It's not in a mergeable state. The ball has been on your side for 4 months @linuxergr.

In my opinion (which is not important since I don't own this repository), it should only contain services for void packages, not for things void might have as a package one day.

All fixed but the dep of bash has not, really do not find it as a such hard issue for a daemon package to be pending or not :) Cheers

[linuxergr]

I understand your point about having only services for sw that exists in the voidlinux repos - that is my objective. But I do not like rejecting frontends that work and represent work on the part of a contributor :)

Totally agree, this was my main point :)

[paper42]

Do you think something like a separate directory for projects not packaged by void would work? The package could then simply install those to /usr/share/doc? Or you could have two packages, one would install the main services and the other one the unpackaged ones?

[mobinmob]

Do you think something like a separate directory for projects not packaged by void would work? The package could then simply install those to /usr/share/doc? Or you could have two packages, one would install the main services and the other one the unpackaged ones?

I was thinking about the second solution - I can do it in a subpackage. void-66-services-oot (oot of tree). BTW, I should send some PRs to void-packages for logging (using vlogger) and some fixes I discover while testing services. The latest issue I found is with the vault service.

[mobinmob]

BTW, I should send some PRs to void-packages for logging (using vlogger) and some fixes I discover while testing services. The latest issue I found is with the vault service. https://github.com/void-linux/void-packages/pull/35384

[mobinmob]

Removed the template for the devel branch, edited README.md accordingly. I will add a subpackage for out-of-tree services, when I make the required changes to the 66-voidlinux repo.