Generate a Pacman package #1
Conversation
|
We should either make paru a hard dependency or edit the script to search for available pacman commands, because if some user installs this package and does not have paru installed it will not work. I'm in favor of searching for pacman commands. It's harder to implement but makes the project more versatile. |
…ompletion Now there are two extra possible commands: The 'dpw help' command shows a menu with all the possible commands. The 'dpw update' command overwrites the packages.ini file with the currently installed packages. This is useful for when new packages are added directly with pacman, paru, yay, etc. Besides, the PKGBUILD now adds autocompletion info about these commands for the fish shell, if it is installed.
|
Hmm, but wouldn't that be like making a whole new AUR helper? I see the helper as a layer of abstraction around the pacman commands and our project as an even thinner layer around this one, just enough to make it declarative. It seems that using only pacman would mean making a new helper, which is fine by me (I would find it really nice actually). But if we are making such a complicated project (paru for example is a huge codebase), shouldn't we use a language more powerful than plain old Bash? If we take on this path of making a new helper, I'd say we publish this as a v1.x.x in its current condition with paru as a hard dependency and then start working on the fully featured helper as a v2.x.x. |
|
It does not have to be that complicated, just searching for an available helper in the executable should be enough, see 7bd58ab. I don't know if all helpers can be executed without using It would be nice to have the option to use it without any wrapper, just |
Added a PKGBUILD to generate the Pacman package to ease the installation of this program.
With this, we could eventually use this action to automate the publishing process to the AUR.