Hey, how do we generally handle forks of packages that we wish to use on the AUR?
For example, we have package A on the AUR and we have A-fork with a feature that is not merged into A due to various reasons (dead projects, other concerns, etc).
Do we create a new AUR package that is based off that fork? Wouldn’t that pollute the AUR with packages that are similar but are forks of each other?
What if I am developing a package B that depends on the A-fork that is not in the AUR? Do I have to create A-fork as an AUR package so that my package B can be built?
Do we create a new AUR package that is based off that fork? Wouldn’t that pollute the AUR with packages that are similar but are forks of each other?
Lots of packages does this already. So I assume it’s okay, if you can’t get the change into the one already there.
What if I am developing a package B that depends on the A-fork that is not in the AUR? Do I have to create A-fork as an AUR package so that my package B can be built?
Yes. You need to make sure all the dependencies are available from either official repository or the AUR when creating an AUR package.
I don’t think there’s concrete guidance.
If the original package is dead, you might be able to convince the AUR maintainer to switch to the fork.
In other cases, maybe a package with <main feature> added in the name could be created. I’d posit Supersonic as an example, where alternative packages exist just for enabling Wayland. It’s still the same upstream, but an additional option in the build is required to enable Wayland.
Similarly, Emacs offers multiple versions with different build flags, though in this case it is using the same PKGBUILD for all versions.
