You are not logged in.
Pages: 1
So... idea I had. Pacman works, I'm not saying it doesn't. My gripe with pacman is more along the lines of its user-facing front (Seriously...who remembers all of the different pacman flag combinations?). My idea was to move pacman more to the style of yum, dnf, or apt-get. Instead of "pacman -S $packages" itd just be "pacman install $packages"
Sure I could do this with bash aliases but that gets pedantic and if I ever re-install Arch I gotta redo all those aliases. Pacman is written in C, and if I patched pacman I'd submit a C patch, if I did something myself (rewrite) I'd do it as C++ or maybe python.
I have little doubt that this isn't something people get EXCITED about (if I'm wrong, thats why this is in Arch Discussion), and if the only person who cares is me... Then so be it. This is mostly a self-teaching endeavor anyway!
That being said... is there anyone else excited / curious / okay with this idea? Has anyone tried this in the past? Did they hit any pitfalls?
Like I said, this is mainly moving forward as teaching endeavor to scratch my own itch and teach myself either C, C++, or python.
Last edited by EGriffith92 (2013-09-28 23:54:17)
Offline
Go for it, this sounds like a good project to learn some coding.
But for your actual questions: who remembers the flag combinations? Me. And most archers. Pacman is a scalpel, not one of those child-safe scissors we had in grade school arts and crafts that you could never quite get your fingers into the grips of. Precision tools require intelligent options and intelligent users. Dull tools are easy to use, but serve little purpose.
I've used other package managers that were initially more "intuitive," but no matter how long I used them, I could never do anything more than the very basic functions with them. Pacman is not as immediately intuitive, but it is easy to quickly learn how to have much more control of your system.
I'm more curious though about your title. You description focuses on replacing the unfamiliar flags with plain language commands. But your title, and the end of your post make vague references to object-based something. What is this? Why is this?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
I'm more curious though about your title. You description focuses on replacing the unfamiliar flags with plain language commands. But your title, and the end of your post make vague references to object-based something. What is this? Why is this?
Probably a local dialect issue more than anything else haha. I chose the phrasing "Object / task" because I couldn't think of better way to phrase what I had in mind. To me "pacman -S" isn't intuitive and is non-obvious to what is going on. If you KNOW pacman commands, sure, it makes perfect sense. But if you don't then you have no idea what the difference is between "-S", "-R" "-Ss" or anything else. So when I came up with the title I was thinking in the idea of "What am I trying to DO?" Hence the usage of "Task" your task is "install", "remove", "search", etc...
The "object" portion of the title... honestly not sure where I was going with that, and I should probably edit the title..
I've used other package managers that were initially more "intuitive," but no matter how long I used them, I could never do anything more than the very basic functions with them. Pacman is not as immediately intuitive, but it is easy to quickly learn how to have much more control of your system.
When you say you couldn't do as much, is there anything specific you had in mind saying that? My original intent was to cover most of the tasks in the Pacman Rosetta page, letting you HAVE your scalpel and do EVERYTHING you already can, but do it in clear and concise language rather than arcane flags.
While sure, I can remember remove, search, install, ignore dependencies... some of the other ones? Not so much. The ones I run into the issue of the most is "File conflict." followed up by tracking down what package owns that conflict (on my tablet so I dont have it off the top of my head). Lets say fstab is conflicted, to see what package owns fstab why not just "pacman whatprovides /etc/fstab". Just an example off the top of my head.
Offline
Seriously...who remembers all of the different pacman flag combinations?
I don't have to. I read the man page and create some aliases / functions, just like with every other program.
There are already some GUI frontends for pacman, you can see what and how they do.
Offline
Nothing at all is keeping you from writing your own pacman frontend. Many have already been written, and some are probably being used every day.
I think you answered your own question.
I have little doubt that this isn't something people get EXCITED about (if I'm wrong, thats why this is in Arch Discussion), and if the only person who cares is me... Then so be it. This is mostly a self-teaching endeavor anyway!
You don't "gotta redo all those aliases" if you reinstall -- I use the same .bash_aliases file on many machines, and I have a separate ".aliases_distro" file that gets pulled in for each different distro I use. I save the aliases on my NFS server and load them each time I do a new install.
How to post. A sincere effort to use modest and proper language and grammar is a sign of respect toward the community.
Offline
On the topic of GUI frontends to pacman... What ever happened to PackageKit on Arch? 7.6 was released on August 21, 2012... Why is Arch not getting the 0.8.x updates? I realize 0.8.x broke the API but it was a GOOD change and drastically increased the performance so why not allow pacman to work with the new API? Does no one care? (if so...why is it still in community? Its basically orphaned BY the distro, not even by the maintainer)
Offline
Well, happy coding. Most of us are lucky, that the days of typing long commands for every day tasks are over. Most of us create and extract tar archives and use regular expression in grep, so you might hit the wrong audience here. I also find it important to have this little reminder, whether I work sync, query, remove or database. So -Ss and and -Qs need to be two different entities. I also don't want to type all day, I got better things to do. Is it really so hard to memorize around five switch combinations? Then there is another problem, you can see it in your example: "whatprovides" is only available as a Q option (-Qo $PATH), the S option requires the seperate pkgfile tool.
I recommend you start writing a wrapper (or try find an existing one). Or how about a simple set of bash functions? You'd be quicker hacking something together, than waiting for any one of us to catch that particular ball.
Offline
The pacman (libalpm) packagekit backend was never maintained by the pacman devs. I believe it was never updated to 0.8, hence it never was updated.
Also, "pacman --remove foo" is the same as "pacman -R foo", but somewhat gives that more detailed option that you are after. Well, maybe not quite...
Offline
Personally, I can never figure out how to do things with yum I can easily do with pacman. Moreover, you only really need to remember one pacman flag:
pacman -h
yum's help spills to screens. pacman's is modular - you call up the help you need with e.g.
pacman -Qh
The only thing I think could maybe be improved is that the output from
pacman -h
could say a couple of words about what each operation is for. Particularly for -Q since it isn't obvious that "query" means locally installed packages and not the database of available packages. This is obvious when you look at the expanded help with -Qh. Similarly, it is not at all obvious that "sync" is the right operation if I want to search for a package.
I think the more detailed help (pacman -{Q,S,D,R,U,T}h) is really clear but the initial help from pacman -h could be slightly more informative. Obviously the man page covers this in great detail but for a quick reminder for people getting used to the flags, I think just a couple of words explaining each operation would be really helpful.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
@cfr: want to file a bug report about that? Or even provide a patch! That is a good point and something that is easily fixed.
Offline
The pacman (libalpm) packagekit backend was never maintained by the pacman devs. I believe it was never updated to 0.8, hence it never was updated.
Is it possible for it to be updated, maybe officially adopted by the pacman devs? Official bug for the lack of a port to 0.8? Blocker bugs (whether in packagekit or pacman itself) preventing it FROM being ported?
0.8 has some nice features and fixes a lot of the synchronous problems that 0.7 showed, so it would definitely be worth updating to as long as its feasible
Offline
OK. I'll file a bug. I couldn't figure out how to add text to the help in pacman.c so I couldn't make a patch. (I wanted to try this, though.)
EDIT: https://bugs.archlinux.org/task/37118
Last edited by cfr (2013-09-29 01:15:56)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
OK. I'll file a bug. I couldn't figure out how to add text to the help in pacman.c so I couldn't make a patch. (I wanted to try this, though.)
Maybe https://mailman.archlinux.org/pipermail … 17780.html will help.
Offline
cfr wrote:OK. I'll file a bug. I couldn't figure out how to add text to the help in pacman.c so I couldn't make a patch. (I wanted to try this, though.)
Maybe https://mailman.archlinux.org/pipermail … 17780.html will help.
Thanks, Karol.
What I couldn't figure out was whether I could just do something like
printf(" %s {-D --database} <%s> <%s>\n", myname, str_opt, str_pkg, "modify database of installed packages");
printf(" %s {-Q --query} [%s] [%s]\n", myname, str_opt, str_pkg, "query database of installed packages");
printf(" %s {-R --remove} [%s] <%s>\n", myname, str_opt, str_pkg, "remove or uninstall packages");
printf(" %s {-S --sync} [%s] [%s]\n", myname, str_opt, str_pkg, "search or update database of available packages");
printf(" install or update packages");
printf(" %s {-T --deptest} [%s] [%s]\n", myname, str_opt, str_pkg, "check dependencies");
printf(" %s {-U --upgrade} [%s] <%s>\n", myname, str_opt, str_file, "install or update packages from local files");
The code a bit further down used a combination of printf and add_list and I wasn't certain how to adapt that pattern. Basically, I know nothing about coding so if I can't just mimic an obvious pattern, I have no idea what to do.
EDIT: If I figure it out, I'll add something to the bug I linked to above. But in that case, I hope nobody is too enthusiastic about the idea as they may be waiting a long time.
Last edited by cfr (2013-09-29 01:26:46)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Allan wrote:The pacman (libalpm) packagekit backend was never maintained by the pacman devs. I believe it was never updated to 0.8, hence it never was updated.
Is it possible for it to be updated, maybe officially adopted by the pacman devs? Official bug for the lack of a port to 0.8? Blocker bugs (whether in packagekit or pacman itself) preventing it FROM being ported?
0.8 has some nice features and fixes a lot of the synchronous problems that 0.7 showed, so it would definitely be worth updating to as long as its feasible
No bugs have been filed in pacman about additional support neeeded for packagekit, so I assume it is all at the packagekit end.
The pacman developers will not be taking over the packagekit backend as official.
Offline
Pages: 1