| Git Clone URL: | https://aur.archlinux.org/octopi-git.git (read-only, click to copy) |
|---|---|
| Package Base: | octopi-git |
| Description: | This is Octopi, a powerful Pacman frontend using Qt libs |
| Upstream URL: | https://github.com/aarnt/octopi |
| Keywords: | aarnt aur automated automatic cachecleaner helper monitor notifier open-source package pacman paru repoeditor update yaourt yay |
| Licenses: | GPL2 |
| Conflicts: | octopi, octopi-cachecleaner, octopi-dev, octopi-helper, octopi-kde-git, octopi-notifier, octopi-notifier-frameworks, octopi-notifier-noknotify, octopi-notifier-qt5, octopi-repoeditor, octopi-sudo |
| Provides: | octopi, octopi-cachecleaner, octopi-helper, octopi-notifier, octopi-repoeditor, octopi-sudo |
| Submitter: | mrbit |
| Maintainer: | class101 |
| Last Packager: | class101 |
| Votes: | 79 |
| Popularity: | 0.066989 |
| First Submitted: | 2013-03-27 11:04 (UTC) |
| Last Updated: | 2024-10-02 20:25 (UTC) |
For me, it's convenient as it improves build time, so we might as well apply it for everyone.
Users have different hardware and runtime requirements. You are overriding their settings (makepkg.conf) for your own convenience. The option is not needed to fix anything, and nothing stops you from enabling parallelism on your own computers without affecting anyone else.
Instead, explain why this change is restrictive, because if you're here, I imagine it's because the change bothers you?
For me, it's convenient as it improves build time, so we might as well apply it for everyone.
If it conflicts with anything, please explain how.
We can always do things in different ways, but in my opinion, mine is the best.
If you tell me that because of this, you're no longer able to do this or that, those are valid reasons since a feature would no longer work.
If it's just a matter of opinion as it seems yet, we simply don't agree.
yes I know, but it's common practice nowadays to unlock it directly on the build
Among packages I've seen, using make -j is common only among packages whose maintainers do not know it's configurable in makepkg.conf. Most remove it after being informed. Otherwise, the option should be used only when needed to work around some bug.
There are old comments for this package asking for -j to be removed. Recent comment on the topic can be interpreted as a request for removal.
If you want parallel builds to be the default, you can switch to cmake and ninja, which automagically takes care of it.
but it's common practice nowadays to unlock it directly on the build
Not in pkgbuilds https://wiki.archlinux.org/title/Makepkg#Improving_build_times
I pushede a commit with $(nproc) instead, it should be similar as --parallel in gradle where it defaults to the number of cpu the user has
Hi, yes I know, but it's common practice nowadays to unlock it directly on the build, I got that on ghidra package and gradle and people arent complaining. I could eventually configure it based on the number of processors of the users; I set it to 8 for now, but it's easy to change it through a variable.
Hello, for parallel build you need to configure makepkg.conf not the pkgbuild, don't have the link right now
TODO
Pinned Comments
class101 commented on 2020-01-28 18:25 (UTC) (edited on 2020-01-28 20:59 (UTC) by class101)
v0.9.0.r332 brings proxy support, thank you @aarnt ! [2250904|e846990]