Pamac CLI

pamac

#142

yes but … no gui ! it is to be written. I think that for software-install it is much better (and easier) to use pamac-installer and users have same gui
there’s just one missing pamac-installer --remove *** for @fhdk


#143

The Application Utility uses glob.glob on the packages list and it went from slooow start to snap.


#144

Au is the Gold symbol on the Periodic Table. (Silver is Ag). :wink:


#145

Disclaimer: I did not read this whole thread, however, I’ve gotten the main points, I think.

In my opinion, pacman is a pretty nice piece of software, and if one thing could be said, it would be that reinventing the wheel is not a good thing unless there is considerable benefit to be had from doing so. As I see it, pacman works very well, and re-implementing it can only really be the source of more fragmentation in the package-management world, as well as more bugs. If you really want apt-like syntax, write a shell script (or even a proper binary) that converts a more user-friendly cli into a pacman command and executes it.

I think the resources of the manjaro development team could be better used to come up with an alternative to every AUR helper out there. As @jonathon pointed out, the binary package repos and the AUR are fundamentally different, and using the same layer of abstraction over them is a Bad Idea™. I would like to see an AUR helper that does not wrap any pacman functionality: it only exists to ease the process of downloading, building, and upgrading AUR packages.

I naively attempted this on my own: https://github.com/MggMuggins/yam
In retrospect, Go was a poor choice of language for such a task (Opinion Warning: any task really), and I would have done better to use D or Rust. I would actively contribute to a project with these parameters if such a project were undertaken (Unless C/C++ were the language of choice).


#146

@SamwiseFilmore: You might not know pamac fully. It uses libalpm, which is the same library pacman uses. Additionally pamac supports the AUR also, without the need of any AUR-helpers. We try to have one package manager with solid UIs thru all of our editions. pacman is a great cli package manager, but not always suitable for our approach. Since we use libalpm we will have the same features as pacman with similar stability. Most of the work is going into pamac-cli and the python-bindings. Also a QT-UI is planned to finalize the pamac family. Only then we can think of making pacman optional. In the end we simplify all the tools existing to manage package to reduce it to one, which fits Manjaro best.


#147

if i use aur ***-git nothing for update ? as

yay -Su --aur --devel

#148

@philm I am very aware of the state of the arch package management situation (namely, libalpm). Just because the library that is used is the same does NOT mean that there isn’t duplicated code between pamac-cli and pacman. I understand the desire to use the same pamac backend for multiple interfaces, but I don’t see the value in duplicating pacman.

I am also a firm believer in not using GUI package managers, but that is just my personal opinion.


#149

Pamac Python bindings are available !


#150

I was trying pamac-cli, to me it feels a bit quicker that pacman, as for the syntax seems to be easy to pick up, pacman syntax never realy stick up in my head and i end up checking the wiki every time i want to do something, although i dont use debian for a few years i still remember apt-get syntax.

for me this is thumbs up :+1:


Pamac-QT - a new QT5-UI for libalpm
#151

Some little feedbacks on pamac cli 6.5.0

  1. What’s the difference between update and upgrade?
  2. Is there a need for a reinstall option ?
  3. Some options are very long to enter and prone to mistakes.
  4. What about some shortcuts, like -h for --help? info -> -i ; remove -> -r ; build -> -b ; checkupdates -> -c ; search -> -s ; list -l
  5. Some options are hidden, like orphan removing. What about an option called removeorphans or somelike this?

I’ve been “playing” with pamac cli for 5 minutes and typed this list of feedbacks.

Besides this, it is a great tool, maybe a little too young :slight_smile:


Pamac-QT - a new QT5-UI for libalpm
#152

No difference

Yes because install option skip already installed packages

I made the choice to use shorcuts for the options not the actions, may be discussed.

pamac remove -o

#153

Thanks for your answers. I know about -o option, but a full option could be better… By the way, thanks for the new makedepends I had to add in pamac-aur-git PKGBUILD… And the new release version… Wow :slight_smile:


#154

The real release will be 7.0.0 :sunglasses:


#155

I understood that seeing number version in command line interface…


#156

Dont forget we explicitly need the equivalent of -Syyu too.


#157

Is that not what pamac upgrade --force-refresh does?


#158

Oh you are right. Still new to me. But great, that means its even split into 2 separate long commands. :stuck_out_tongue:


#159

I think it was eugen who said something quite acceptable - pacman will be treated as dpkg against pamac being apt. Keeping both is such low overhead I dont see why not. We still get the benefit of unifying help responses and instructions on a ‘every system has’ pamac.
If this were the direction I would be much happier. Implement and normalize pamac all we want. awesome. but leave pacman alone. I’m kinda repeating myself, but I feel that would make everyone happy.


#160

I hope that is not the syntex used 5 letters replaced by 22 if so your going backwards not forwards


#161

Well, yeah, re-inventing the wheel hasn’t turned it into a sports car yet. :wink: