Replacing pacman via pamac-cli


#40

No that is not true that is fabricated by a few Manjaro/Arch users with nothing better to do than bitch?


#41

Thank you for clarifying
Seen some patronising posts in the past about Manjaro, but generally ignore that sort of thing


#42

I don’t get it. This is my only distro since I left windows. It took some time to get used to the abstract commands, but now I love it.
Whoever wants to talk “ubuntish” to pacman should do this with aliases.


#43

I feel like I am missing something here.

pacman is a just a front-end to libalpm. The actual package management heavy lifting is handled by libalpm.

pamac is also a front-end to libalpm.

If you prefer using pacman you can still install it and use it.

Is this really a big deal?

If such a package exists, wouldn’t it be better that it actually not work?

Why would the Arch devs care if Manjaro stops including pacman? From the outside, it appears as if they have no desire to directly support the users of Manjaro or any other derivative distro.(Honestly, why should they be asked to support users of other distros?) I would think using different tools would make that easier for them.

Currently, it is all in one package. I believe the idea is that the pacman package would be split on Manjaro.


#44

If the goal is to have Debian-like syntax for certain user-group familiarity, it is simple.
There you are (not many, but it is a start}.

Arch Debian Arch-Apt Alias
pacman -S apt install arch-apt install alias arch-apt install=pacman -S
pacman -Rs apt remove arch-apt remove alias arch-apt remove=pacman -Rs
pacman -Ss apt search arch-apt search alias arch-apt search =pacman -Ss
pacman -Syu apt update arch-apt update alias arch-apt update

Aliases

alias arch-apt install=pacman -S
alias arch-apt remove=pacman -Rs
alias arch-apt search =pacman -Ss
alias arch-apt update|=pacman -Syu


If you like it, then I 'll make this a Wiki so it can be contributed :hugs: (I’m so lazy…)


#45

pacman is a known quantity. It is well-written and does one thing well.

Pamac is a GTK-based GUI front-end. And also now a CLI front-end. And also now an AUR helper. And also now wanting to be a Qt-based front-end. It is the very epitome of “feature creep”.

“Reinventing the wheel” is the perfect idiom here. We have a wheel (pacman). It performs its job perfectly.

Now, someone wants to create a new wheel because they didn’t create the other wheel, or it doesn’t have enough spokes, or whatever.

“Because we can” is not a valid reason for making a change.

The other relevant term is “not invented here” (NIH). This is a trap Canonical fell into very early on when they decided to reimplement - from scratch - tools which already existed and worked well and which they would end up adopting anyway.

uSplash (Plymouth). Upstart (sysvinit/systemd). Unity (GNOME3). Mir (Wayland).

Every time they spent time redeveloping an existing solution it caused unnecessary fragmentation and set back their own distro development.

A little while ago I started this thread,

because the naming similarities between pacman and pamac confuse a large number of people. I got confused between the two when I started using Manjaro.

Now we’re considering dropping pacman in favour of pamac? What chaos is that going to cause when all of the available information on the web is for running commands with pacman? All of the upstream projects with installation instructions which refer to pacman? All of the content on this forum which refers to pacman? When people try running pamac -Syu and finding it doesn’t work? Or install AUR packages without knowing what they are because it’s enabled in the default installation tool?

On my list of weird decisions a distro has made, this would make it into the top few.

(I think my top “weird decision” was Ubuntu’s by-default sending all keystrokes to a third-party server to enable Amazon product advertising in the Dash)

I know I’ve said Manjaro has the potential to do for Arch what Ubuntu did for Debian, but I didn’t mean we should start acting like Canonical…


#46

Wow @jonathon at last somebody on the team is speaking sense, I saw the Ubuntu fault creeps and walked away its pointless why try to be clone Ubuntu. As i’ve said being No 2 in the rankings is a good place being No 1 their is only one way down, Ubuntu fell through bad decisions, Now mint has fallen again bad decisions do you really want Manjaro to go the same way, think before making mistakes that can be avoided.


#47

Thank you, @jonathon! I was concernedly following this discussion and as much as I love manjaro, I cannot even believe why moving away from pacman could be a good idea in any way.

Package manager fragmentation is one of the -sorry- most idiotic things in the linux world. Yes, there are differences between them and, yes, pacman is a good one. But, please, do not add another to that already too long list!

And I have to say this:
Pamac is nice. But it was never completely stable (one example are the continuous crashes when the “details” view is open). With larger updates and especially larger AUR installations I tend to turn to pacman (or pacaur etc.).
Don’t get me wrong, it is nice to have a GUI tool for that, but pacman is rock solid, pamac never really was.

Until pamac can be kept rock solid for, say, two years in a row, without a hitch, no one should even think about replacing pacman. And even then: Keep it a GUI tool. Stay with pacman, it is just fine.

One more thing is to think of the users. Manjaro aims to be a simpler to use, more stable Arch (yes, there might be other goals, but in fact, that is what it is!). If there are not-so-experienced users, they can currently use cli-solutions from the net. The pacman-syntax can simply be copy/pasted. (Yes, people shouldn’t without understanding it, but who are we kidding, didn’t we all start that way?).

All those solutions would be lost to Manjaro users until they are educated to exchange every single “pacman xyz” command for “pamac-cli xyz” (if that thing stays even syntax compatible, which I doubt somehow).
Why should that be a good idea?

And if someone said “then lets make it a default alias”, my answer would be, “why, then, bother with replacing it at all!”.

And adding to that: There are several scripts out there, which use pacman to install various software packages. All those would be broken.

And so many more reasons! This is simply a terrible, terrible idea.


#48

Oh, yes, I almost forgot:

:woman_facepalming:


#49

I like the idea of adding a Qt interface to Pamac. I also like the idea of renaming Pamac. I also have no problem with simplifying the command structure for new users.

Where I have a problem is with removing pacman and its syntax from the distro. As already mentioned all pre-existing documentation on the internet uses pacman syntax. So, while on the one hand it makes support requests easier to deal with because of a unified interface and built in AUR support it will create other problems.

The standard expectation is that before you create a help request, you search for an answer. Unfortunately most of the information on the internet will refererence pacman commands and no longer apply to Manjaro. This may actually result in far more help requests on the forum as new users will be unable to understand why the stated commands do not work.

In addition, has nobody considered that all the wiki documentation will need to be changed to reflect new command usage? The only way to prevent all this turmoil would be to make Pamac support the old pacman syntax in addition to the new simplified commands.

I really think pacman commands need to continue to be supported for the foreseeable future. Manjaro does not have the resources to create and maintain a comparable resource to the Arch Wiki. The information on the Arch Wiki needs to be applicable in Manjaro unless a huge amount of effort is put into creating a comparable Manjaro Wiki. That’s just a massive undertaking and would be almost impossible to accomplish.

I think more thought needs to be put into this before it’s implemented. Pacman and it’s associated commands are too deeply ingrained in all documentation on the internet to be removed completely in my opinion. Please rethink this policy before committing to its implementation.


#50

I have been trying to use the pamac cli for the last week just to see how it goes. It is confusing. They are way too close in name.


#51

The practical difficulties pointed out @jonathon and @tbg and others will probably lead to the last step - dropping pacman - won’t be made in the end. But there is hope: pamac could be in development and when it is ready to replace pacman it could be renamed the new name being pacman. :space_invader:
(How to set a countdown to the April 1st with Discourse?)


#52

That would create some epic chaos. :scream:

Have the command have the same name but different syntax.

I like this idea. :grin::grin::grin::grin::grin:


#53

Why?

A new “interface” is not simply being added … a new application needs to be developed in a completely different framework by a different developer.

So you have two “identical” applications developed by different people and for what? They will never be “identical” there will always be inconsistenies between them.

GTK based apps work fine in Plasma, so this is pointless.

If possible this makes even less sense than replacing pacman, replicating a potentially core package management tool in a different framework, when there is nothing wrong with the existing tool.

The mind boggles.


#54

You jest … but … :man_facepalming: :woman_facepalming:


#55

OK what is wrong with pacman that it needs to be replaced? Please don’t ruin a perfect dristro for me. One the reasons I switched to Manjaro is because it is Arch based. And pacman is one of the best package managers out there if not the best.


#56

I thought they were just adding a UI that either made dbus calls into the existing pamac daemon or used the new python bindings. Isn’t the pamac-manager gtk frontend just a simple UI for the daemon at this point?

I wouldn’t think it would be that much work to put together a new UI in qt.

Honestly, I don’t disagree with you but every time I have ever suggested this people come out of the woodwork to talk about how they don’t want gtk apps in their qt-based DEs.


#57

well for me replacing pacman is actually kind of a good idea as the syntax pacman uses doesnt always make sense from a new users perspective.
If it works more like apt from a command line standpoint I am all for it.
But then again I kind of have a Debian bias after being under the apt umbrella for so long, and under Ubuntu apt is even better with the user only having to type sudo apt install (packagenamehere)


#58

Well back when I used KDE 3.x.x I’ve had both QT and GTK apps in the same DE and never had any issues with it.

I really don’t see what the problem is really.


#59

Personally, I’m indifferent to replacing, as long as pacman is still available.

On the other hand, if the idea is to integrate all package management tasks into pamac, I think we should also look into adding pacman-mirrors functionality into pamac-cli, the same way that such functionality is already available to pamac-gui.

A new user with no prior arch-based experience will install manjaro, get used to pamac as the default package manager (whether gui or cli), and find it odd that he/she needs to do “pacman-mirrors -f” to refresh the mirror list since pacman per se is not a known entity to the user.