[arch-dev-public] Can we have optional deps on AUR packages?
Moving this discussion from aur-general. I posed the question: I just wanted to clear this up with the other TUs: Is it ok for [community] packages to have optional deps on AUR packages or not?
On 19.04.2017 21:50, Sven-Hendrik Haase wrote:
I just wanted to clear this up with the other TUs: Is it ok for [community] packages to have optional deps on AUR packages or not?
We generally tell people that we do not support AUR packages and because of this there are no AUR (download/install) helpers in the repos. If you start adding such dependencies that goes against this idea of separation. Actually I can't even think of a way to explain why AUR helpers and AUR packages are not supported while at the same time telling people to install them. This just doesn't fit. Just pull the packages into the repos or don't include the deps. Florian
Em abril 19, 2017 17:47 Florian Pritz via arch-dev-public escreveu:
Just pull the packages into the repos or don't include the deps.
I also think we shouldn't depend, even if it's an optional dependency, on AUR packages. In ansible's case, since those two are python libraries, I think it's ok to bring them in to [community]. If you want, I can help co-maintain ansible (and deps), since we depend on it for the infrastructure repo. Cheers, Giancarlo Razzolini
On 04/19/17 at 11:18pm, Giancarlo Razzolini wrote:
Em abril 19, 2017 17:47 Florian Pritz via arch-dev-public escreveu:
Just pull the packages into the repos or don't include the deps.
I also think we shouldn't depend, even if it's an optional dependency, on AUR packages.
As I already said in aur-general, I agree that we should keep this separate to avoid confusion. -- Jelle van der Waa
On Wed, Apr 19, 2017 at 09:50:54PM +0200, Sven-Hendrik Haase wrote:
Moving this discussion from aur-general. I posed the question:
I just wanted to clear this up with the other TUs: Is it ok for [community] packages to have optional deps on AUR packages or not?
I would definitly pull all optional deps to [community]. There are several reasons for this: 1. Good PKGBUILD quality, because the maintainer of the package that has the opt-dep controls also the opt-dep in community and can enforce a good PKGBUILD. 2. Less Confusion. If we start adding AUR optional-dependencies to our official packages this would confuse people, even if we declare it in the PKGBUILD. 3. Control. If the maintainer is busy or in vacation another maintainer of [community] can takeover his job for some days/weeks, without moving package ownership like we often have in the AUR. 4. More Security. AUR packages mostly don't include all security features. 5. Time. The user doesn't need to recompile it by theyself. 6. It's a clear statement that we don't support the AUR. 7. It's easier for the user. Best regards, chris
participants (5)
-
Christian Rebischke
-
Florian Pritz
-
Giancarlo Razzolini
-
Jelle van der Waa
-
Sven-Hendrik Haase