that's true, but it is a way for me to keep package generation disctinct from my server which helps me a lot.
In that case, you might take a look at aurutils - after 2 years, it remains the only helper centered around local repos.
i just wanted to understand the reason why there is nothing official and supported.
Well, the helpers are supported by their respective authors (those that are still active anyway). Just don't file bugs on bugs.archlinux.org when something breaks using them.
]]>There's a great alternative for aur helpers
What? It's an addition, not an alternative. A local repo alone won't solve AUR dependencies or retrieve new versions to be built.
that's true, but it is a way for me to keep package generation disctinct from my server which helps me a lot.
btw my original question wasn't meant as a complain for dependency management. i just wanted to understand the reason why there is nothing official and supported.
]]>There's a great alternative for aur helpers
What? It's an addition, not an alternative. A local repo alone won't solve AUR dependencies or retrieve new versions to be built.
]]>There's a great alternative for aur helpers : put aur packages you built in your own custom local repository and add that repo to the bottom of your /etc/pacman.conf .
Mine currently holds 62 packages.
thank you!
that sounds like a good solution and reminds me of gentoo overlays (which i am more used to). will look into it!
]]>Mine currently holds 62 packages.
]]>I use a 167 line python script (of which ~55 lines are just imports and customizable format strings for displaying output) that can search, check for updates, recursively download and sort dependencies into a list of the order in which they should be built, and has a handful of possible display/output formats.
Even at 167 lines, I periodically review the code and think it's a bit bloated for my tastes.
If you can review the code and understand what an aur tool is doing for you, then you should have no concerns about using it.
]]>How does that handle dependency change due to a PKGBUILD edit?
Why would it? If you want different dependencies, it's easy to keep a local fork or propose it to the maintainer. With everyone using git nowadays, you could even use git merge/rebase.
i guess this is the reason why there is no official aur-helper (my original question)?
i dont really like it, but i can understand that reasoning
No, because helpers which don't wrap pacman aren't official either. (well, cower was for one day!)
The reason, as linked on the top of the AUR helper wiki article:
https://bbs.archlinux.org/viewtopic.php … 10#p828310
edit: fixed link
]]>That's how yaourt does it, since 2008. Anyone else uses the RPC for dependency resolution since it's a far more robust approach and doesn't require endless prompting during the build process.
How does that handle dependency change due to a PKGBUILD edit?
]]>Which doesn't exist. (inb4 wiki table, which "recommends" pacman wrappers: these are actively harmful both in removing the distinction between AUR and repos, and claiming to be pacman while doing arbitrary weird things).
i guess this is the reason why there is no official aur-helper (my original question)?
i dont really like it, but i can understand that reasoning
So that the PKGBUILD post editing is used for dependency evaluation.
That's how yaourt does it, since 2008. Anyone else uses the RPC for dependency resolution since it's a far more robust approach and doesn't require endless prompting during the build process.
]]>Why would it have to stop after each clone? Clone does not involve code execution, so you can just view all PKGBUILDs, .install files, etc. after retrieving them.
So that the PKGBUILD post editing is used for dependency evaluation.
]]>namely full access as the user running it including creating and modifying packages that you will then install with root permissions.
Assuming you don't use sudo or makepkg -s.
If the tool is not stopping after each clone and letting you check the PKGBUILD before cloning the first dependency of that PKGBUILD or
before building that dependency then you would only have checked the PKGBUILD of your target package.
Why would it have to stop after each clone? Clone does not involve code execution, so you can just view all PKGBUILDs, .install files, etc. after retrieving them.
use a helper that is at least recommended.
Which doesn't exist. (inb4 wiki table, which "recommends" pacman wrappers: these are actively harmful both in removing the distinction between AUR and repos, and claiming to be pacman while doing arbitrary weird things).
]]>flower wrote:but they decide which dependencies to include. how to build and install them.
The PKGBUILD controls the dependencies which you are expected to check for correctness. You are expected to build the dependencies so you would control how they are built.
You are expected to install the dependencies so you control that as well.
Edit:
grammar to not is
well true. but with that logic i can just go LFS.
i use a package manager because i dont want to do manual dependency management.
checking is ok (and imho mandatory for something like AUR), but cloning any dep and build it (recursivly) is to much (at least for some packages)