Just out of curiosity, is there any underlying reason one can't AUR dependencies directly in a PKGBUILD? I get that it's usually a bad idea, but I'm just curious as to why it hasn't been implemented?
Last edited by elken (2014-03-30 15:07:12)
I do not understand your question. You can have dependencies to AUR packages in your PKGBUILD, and it is common practice.
I get that it's usually a bad idea...
I'm just curious as to why it hasn't been implemented?
Uh, because of that thing you just said. ? ?
I'm guessing you mean why can't links to the dependencies be included in PKGBUILDs. I don't have a definitive answer, but there are probably several reasons not to do this, all probably owing to potential headaches from overly complicating such things or setting hard dependencies, e.g.:
1) Suppose user a downloads package x, which has dependencies y and z. When y fails to build, a mistakenly treats the whole dependency array as a subset of package x, and complains to the maintainer of x or marks x as out-of-date when y is the problem. Making users build packages one at a time avoids that confusion and annoyance.
2) Multiple variants of a dependency may exist, and while the vanilla one suggested by upstream probably works fine, the end-user might want to use a specific one. provides= makes that possible. It also allows for a short-term work-around to example 1 above.
3) The flexibility of PKGBUILDs would decrease. Packages can change over time; hard-coding dependency fetching into the PKGBUILD could lead to packages breaking because, as dependencies (and links to them) change over time, multiple PKGBUILDs might need to change rather than just one. Having to change links occasionally wouldn't really be different than how things are now, but the reasons for changes can vary. If a package is a dependency for multiple other packages, and those packages all require different versions of the dependency, it's not hard to imagine how things might break down at some point.
4) Probably a bunch of other stuff. The fact is it's never been implemented in the roughly 12 years Arch has been around, probably because the benefits (minor convenience) are outweighed by the costs.
Last edited by ANOKNUSA (2014-03-30 14:31:51)
I guess, I just thought there was another reason to it. Thanks though.
In case you aren't already aware, there are various utilities, ususally called "AUR helpers", which can automate the aur-package-building process in various ways. Many of them provide automated building of dependencies, which would address your question (unless I misunderstood your question, which was not very clear).
I think clarifying the question would help. If you want to know why you can't list AUR dependencies, then there is no question: you can.
If you want to know why makepkg doesn't build AUR dependencies while/before building a package, then ANOKNUSA's answer applies, but this would then not be a PKGBUILD question, but a makepkg question.