Actually, AUR already has neoarch-git. -git is for beta/development releases, while neoarch is for stable releases.
Maybe as an advanced feature it could be. I’m just looking at this as someone who may come from windows and doesn’t know crap about crap. I assume if the package manager lets me do it then its fine. While in cases holding back packages is completely legit at times I never feel like packages on a Rolling release should be “Locked” for long periods of time. Mostly a few weeks. If no resolution to the issue is at hand at that time then maybe time to reevaluate the need for such tool and search for alternatives. I just see it as a security risk to run something without updating it since the update could be an important security update.
I agree with @thefrog a GUI tool should not support partial upgrades in any way, even with a warning.
Users will ignore warnings and the potential for breakage is much higher than the value of being able to hold a package back or upgrade a single package. Both of those activities are only things that should be done by advanced users. I think it is fine to force people to the terminal for those activities. We are talking about things that can absolutely make your system unbootable. Don’t give the user an easy way to do that and then have them in a situation where the system is broken.
Yeah, if you lock a package because a newer version breaks something, NeoArch respects that and won’t upgrade it. You can un-ignore/un-hold it later from the package menu or settings.
If the newer version is the problem, you can also downgrade to a cached version and pin it so pacman doesn’t pull the broken version again.
One thing I haven’t handled yet is automatically reminding you that a pinned package is still outdated. That’s probably something worth improving.
Also, if you’re interested, feel free to contribute to NeoArch. Some parts of the package-management side are pretty deep and there are things I’m still learning myself. If you see something I’ve misunderstood or something that should be fixed, a PR or issue would honestly be helpful. I’d rather have someone with more Arch experience help improve those parts than pretend I know everything.
This is where everything seems off to me, I am just being direct but if I was going to attack linux at the moment this is how I would start. Again I have no evidence but the answers are always you right here is the answer in this thread (apolisgise if wrong, but yer do not like this at all, like i’ve said a few times something off here)
I’m going to rethink that part of NeoArch and probably force those advanced operations to the terminal instead. I’m doing NeoArch as a hobby alongside my daily job, so I need some time to properly test things and find a better approach rather than just changing it quickly.
And just to be clear, this isn’t vibe coding for me. I need to understand what the code is actually doing, especially with package management, before I make changes to the GUI. I’d rather take a week or two, test it properly, and make the safer design change.
think this easy “change this part”? actually behind scene its not easy need to check codebase and sub modules and this app i divide as front end and backend as for easy need to think deep hard to change. No contributors, no pull requests, and no one helping with testing so far. So yeah, this isn’t easy to maintain alone. I’m doing the development, testing, bug fixing, and improvements myself alongside my daily job.
Well there are several issues here but I’ll address one. You joined the forum and the first thing you did was spam your project. Not come in Introduce yourself and help assist other users in issues. You offer no support to the community then seem surprised that no one has offered you any. You are not the first person to join the forums and push your projects and offer nothing in return so most are already burned out on these types of projects and request.
I joined this community mainly because I wanted to share NeoArch and get feedback from people who actually use Arch and know package management much better than I do. That was the purpose of my post, not to ask the community to maintain it for me.
I’m still learning, and I’m happy to take the criticism and improve the project. I also understand that I should spend more time contributing to the community itself, not just talking about my own project. I’ll keep that in mind.
If you have any ideas from an ease of use, security, or arch-specific perspective, I’d love to hear them. I’d rather improve my design based on real user feedback than assume it’s right. This is the main reason. I’ve asked more from the community and added more things to fix and improve. I have some great ideas for future development.
i post screenshot ,Don’t be fooled just because someone says, “The app is good, download it.” If the project is open source, you can check the code yourself and see what the developer is actually doing.
One thing I’ve learned from sharing NeoArch with the EndeavourOS community is that not everyone will like the idea, and that’s completely fine. Some people laughed at it or called it useless, but I don’t want to focus on that. I’d rather listen to the people who actually try it and give useful suggestions.
I especially want to thank Brian_Masinick for his comment. He actually tried NeoArch, found a way to run it, and confirmed that it works well for him as a GUI package manager on EndeavourOS. That kind of feedback really motivates me to keep going.
And I’m happy to say that NeoArch is still growing. Just last night I added support for 10 languages:
English, 
Spanish, 
Sinhala, 
Hindi, 
German, 
French, 
Portuguese, 
Simplified Chinese, 
Russian, 
Turkish, and 
Japanese.
All of them are fully translated now, and I’ll keep adding and improving things day by day.
So thanks to everyone who has tested NeoArch, reported issues, suggested improvements, or even criticized it in a useful way. I’m still learning, and every good suggestion helps me make it better. 
and future updates im add endeavouros theme for my app.finally thanks all very much
Arch has also tools to fix disowned packages you can also merge into maintenance stuf to make compatible with those tools like paccheck pacrepairdb idk exact name need to look at it. Is always i like and dont like. But just got respect for any efforts on any project, blood and sweat never is wrong.
And thanks for mentioning paccheck / pacrepairdb. I’ve heard of those maintenance tools, but I need to properly look into how they work and how they could fit into NeoArch’s system maintenance features. I don’t want to just add something without understanding it properly.
I’ll put this on my TODO list and investigate it. There are probably quite a few Arch maintenance tools that I haven’t covered yet.
Hi @sanjaya
I’m developing archcanary, also with Claude Code Pro.
You don’t hide the AI use — true — but you don’t really advertise it either. It helps to make it explicit in the README: what’s AI-assisted, and that you review it before committing. That earns more trust from users in the long run.
I won’t comment on the tool itself or whether it’s useful.
But I saw you added a PKGBUILD scan. archcanary has an on-demand PKGBUILD scanner too (–check-pkgbuild, plus an optional yay hook). I took the Unicode look-alike / homograph detection idea from your security_scan.py and I’m adding an equivalent check to archcanary now — Cyrillic/Greek/Armenian look-alike or hidden characters in url=/source= values.
If it’s useful the other direction, here’s how archcanary does its PKGBUILD checks: https://github.com/musqz/archcanary — check_pkgbuild_caches in archcanary.sh, and configs/yay-init.lua for the yay 13 hook.
Thanks for sharing your project. 
Hey, thanks for the detailed reply. I read through the archcanary repo and I think there’s a lot of useful work there.
From what I understand, archcanary is a read-only security scanner for Arch. It covers things like AUR malware indicators, systemd/eBPF persistence, npm/bun/pnpm/yarn cache poisoning, suspicious PKGBUILD patterns, ld.so.preload injection, autostart/RC files, DKMS and kernel-module related checks, and Lynis-based hardening checks. I also noticed the PKGBUILD checks look for things like obfuscated commands, base64 -d | sh, eval combined with downloads, and similar patterns.
I also checked the implementation because security tools need to be handled carefully. I understand that those dangerous-looking strings are detection patterns, not commands that archcanary is actually executing. I also saw that the project is designed to be read-only and that the AI-assisted code and documentation are reviewed before being committed.
Personally, I don’t think using AI as a development tool is a problem. It can help us build things faster, explore ideas, and make development more accessible. If an idea is good and helps make Linux or open-source software better, I think we should use whatever tools help us make it better.
Regarding integration, I think archcanary could fit really well with NeoArch. NeoArch’s PKGBUILD review is mainly about checking a package before installation, while archcanary can inspect the installed system for persistence, poisoning, and other security issues. So they could complement each other rather than duplicate each other.
I’d be interested in adding an optional “Run archcanary scan” action in NeoArch’s Security Settings when archcanary is installed, instead of bundling your script into NeoArch.
Also, if you’re open to it, would you consider adding NeoArch to archcanary’s documentation/projects list as a project that can optionally integrate with or use archcanary? I think it would be useful for people using both projects.
And if you have any conditions or preferences for the integration — licensing, attribution, how you want archcanary invoked, or anything else — just let me know. I want to make sure I do it properly and respect your project.
Thanks again for sharing the project and the PKGBUILD security ideas. I’ll definitely keep looking at what we can learn from each other.
what do you think?
I need some time for a reply. To be continued…this could be a discussion on github.
(post deleted by author)
Hi musqz,
I wanted to reach out regarding a planned use of your work in another project.
What we’re building: NeoArch is a GUI package manager for Arch Linux that supports discovering, updating, and uninstalling packages from pacman/AUR, Flatpak, and npm. We’re also planning to include a PKGBUILD security scanner in neoarch/backend/services/security_scan.py, exposed through neo scan <PKGBUILD> and integrated into a pre-install dialog that gates AUR installations.
What we’re planning to incorporate: We’re planning to port the detection patterns from your --check-pkgbuild layer into our own scanner, including the layered-defense rules for:
-
ANSI-C
$'\x..'byte assembly and printf-hex command spelling -
variable-split reassembly (
a=x; b=y; $a$b) -
Tor/SOCKS-proxied fetches (
torsocks/proxychains) and.onionURLs -
downloads directly into system paths
-
ssh://aur@aur.archlinux.orgself-propagation -
non-interactive
pacman --noconfirm -
duplicate
source=()entries and mutable MR/PR diff sources
We would not run or re-ship your scripts. We plan to incorporate the relevant rule logic under the MIT license and include the appropriate attribution and license notice in the code. The resulting scanner would be fully self-contained and would have no runtime dependency on ArchCanary.
If you have any concerns about this planned use or would like to compare rule coverage or cross-test the scanners, I’d be happy to sync.
Thanks for the solid foundation. and i open issue in github thank you
Perfect … I have no concerns about the plans using parts of archcanary. The beauty of opensource. I am it can be usefull for your project.