Merge servarr stack

[txtsd]

It's my first time contributing in this repo.

I'm going to use ${servarr} as a variable to denote any *arr app to explain what this PR aims to achieve.

${servarr} and ${servarr}-bin should be the same version.
${servarr}-develop and ${servarr}-develop-bin should be the same version, and they are development versions.
${servarr}-nightly and ${servarr}-nightly-bin should be the same version, and they are also development versions.

Please let me know if my yaml-fu is correct, or if it needs changing~

[AMDmi3]

• Please don't put these into separate file, this makes it harder to look for rules. Rulest should be spread alphabetically.
• Please only merge names which are not currently merged. For instance, for sonarr, only sonarr-develop needs merging, not sonarr-bin, sonarr-develop-bin, sonarr-nightly, or sonarr-nightly-bin
• -develop and -nighly merges need weak_devel: true, nolegacy: true instead of flavor

[txtsd]

Rules can be easily grep'd for. I didn't think that would be a problem.

Regardless, I'll make the changes!

EDIT: Are -bin packages automatically classified under their main project? If so, should I remove the -bin for sonarr?

[txtsd]

Okay, ready for re-review!

[AMDmi3]

Like I've mentioned,

• You don't need flavors for nightly/develop. Note that you can also stick nightly and develop into the same rule where applicable.
• Please don't merge non-existing projects. Check project search first, if there's no e.g. whisparr-nightly-bin, rules should not mention it.

EDIT: Are -bin packages automatically classified under their main project? If so, should I remove the -bin for sonarr?

This depends on repository. They are for aur but aren't for gentoo, and that rule is needed for gentoo, so no, please don't remove it.

[txtsd]

The nighties and develops should be the same version each respectively though. Is that handled without flavors?

[AMDmi3]

The nighties and develops should be the same version each respectively though. Is that handled without flavors?

Repology does not check version equivalence between packages. develop/develop-bin/nightly/nightly-bin will be handled independently, but the same way, ignored if version higher than release version and outdated if lower.

[txtsd]

Okay, ready for review again!

The *-nightly packages on the AUR have been merged into *-nightly-bin, so there aren't any *-nightly, there are only *-nightly-bin now.

[txtsd]

Rebased on master

[AMDmi3]

• Please don't merge non-existing projects

This has not been fixed yet. See comments for examples.

[txtsd]

Now it makes sense!

I was thinking in terms of packages, not projects.

I've got the hang of it now for future contributions!

Ready for (hopefully final) review~

[txtsd]

Can you also show me how to mark some repositories' packages as develop?

For example in radarr, Chocolatey, Gentoo, and LiGurOS develop package the develop versions of radarr so the actual stable versions are shown as outdated.

[AMDmi3]

Can you also show me how to mark some repositories' packages as develop?

We just mark these repositories as untrusted. Marking version range as devel is possible, but that would require regular manual updating of a rule, we don't want that. It would be better if upstream conveyed release status in a versioning scheme, such as using -betaX suffix or even/odd approach. It looks like bazarr does use beta suffix, and in fact we can remove weak_devel from its merge rule as long as we trust bazarr-beta to always have beta suffix.

[txtsd]

Okay I'll open a new PR for the rest of the packages. Thanks for showing me how!

I'm the maintainer of bazarr-beta. I can guarantee it will always be beta.

Also, how often is the website updated?

[AMDmi3]

Also, how often is the website updated?

Once each 4-5 hours.

[txtsd]

I see ruleset: liguros, but I don't see a way to specifically target LiGurOS Develop.

Without that we'd have to make a rule for each develop version that lands 👀

[AMDmi3]

We just ban whole repository (which provides unstable version) untrusted, you don't need to specify versions for that.
And you can just use ruleset: gentoo which would affect both gentoo and liguros.