Pacman evolution

Caspian · 2008-01-16 11:19:07

I was recently using Gentoo for server purposes (wasn't my choice ). It is a great distribution, but the thing that impressed me the most was portage (and emerge tool). I was just wandering are there some plans for pacman to gain more search options, true color output (not some quasi add on solutions and so on...). Guys, don't get me wrong pacman is great but i just want to know what are the plans for our future pacman ?

shining · 2008-01-16 14:30:49

I guess this depends on what users plan to contribute to pacman

There was one thing related to search options from the TODO lists :

* feature for 3.1: multiple search/match types
option: MatchType regex (current way)
MatchType fnmatch (use fnmatch to match things like 'pacman -S gnome*')
MatchType plain (no matching. expect plain text).

Finally, what was done in pacman 3.1 isn't what was listed there. No option were added.
However, pacman 3.1 now does both a regex and a plain search, on a -Ss operation.
So for example, pacman -Ss dvd+rw-tools works now, while it didn't work before with 3.0.

About colors, vogo proposed a patch. And Nathan updated it to 3.1 :
http://archlinux.org/pipermail/pacman-d … 10791.html
But I am not sure the devs have a high interest in this. So any help is welcome for discussing / reviewing / improving this patch.

shining · 2008-01-16 16:10:25

By the way, vogo also made a pacman-color package for 3.0.6 on AUR back then.
He wasn't even aware Nathan updated his patch to 3.1
I told him, so he should be able to update his package easily now, and you will be able to try it then.

neotuli · 2008-01-16 17:10:57

afaik the color output patch isn't going to get accepted. See toofishes for the gory details.

phrakture · 2008-01-16 18:14:56

Caspian wrote:

I was recently using Gentoo for server purposes (wasn't my choice ). It is a great distribution, but the thing that impressed me the most was portage (and emerge tool). I was just wandering are there some plans for pacman to gain more search options, true color output (not some quasi add on solutions and so on...). Guys, don't get me wrong pacman is great but i just want to know what are the plans for our future pacman ?

Sadly, in a package manager, searching and colored output are really the least of the worries. There are lots and lots of planned features, and you're more than welcome to read through the source, and follow the pamcan-dev mailing list if you're interested

shining · 2008-01-16 18:56:44

neotuli wrote:

afaik the color output patch isn't going to get accepted. See toofishes for the gory details.

Right, we discussed about this, and he said he doesn't want to add colors to the default pacman frontend, and that C + colors is messy.
But everyone is welcome to keep maintaining a package in aur that simply patch pacman, like the pacman-color package maintained by vogo.
Someone could also start an alternative ncurses frontend (using libalpm) which should be nicer for getting colors.

ekerazha · 2008-01-16 19:07:39

Well... I've worked for about 3 months on some ideas in order to improve the current pacman backend, writing hundreds of - unuseful - C lines. I've now a deep knowledge on how pacman works and I can say, without any fear, that the current backend is a really unefficient mess.

The best solution, imho, would be a sqlite based backend: I began to write a patch too, but having a sqlite based database only for the [local] database in just stupid, the remote databases (downloaded by pacman from the repositories) should be sqlite based too... so devs have the last word... but they don't like the sqlite approach (well... some of them don't even know what sqlite is, I remember about a developer who thought sqlite was "daemon based" just like MySQL or PostgreSQL).

Last edited by ekerazha (2008-01-16 19:16:17)

Cif · 2008-01-16 19:27:41

Yeah... give pacman more speed... we're in 2008...

Cerebral · 2008-01-16 19:29:55

Cif wrote:

Yeah... give pacman more speed... we're in 2008...

What does that even mean, "we're in 2008"? What's slow about pacman? They just gave us great speed-ups in 3.1 - just compare -Qo before and after.

shining · 2008-01-16 19:30:16

Cif wrote:

Yeah... give pacman more speed... we're in 2008...

It's never too late to start...

toofishes · 2008-01-16 19:38:41

Cif wrote:

Yeah... give pacman more speed... we're in 2008...

Patches welcome.

Cif · 2008-01-16 19:51:22

toofishes wrote:

Cif wrote:
Yeah... give pacman more speed... we're in 2008...
Patches welcome.

Really? say it to Danimoth...

Cerebral · 2008-01-16 21:23:14

Cif wrote:

toofishes wrote:
Patches welcome.
Really? say it to Danimoth...

"Patches welcome" does not mean "we will apply each and every patch you ever send us" - it means that you're more than welcome to submit patches for things you think should be changed.

Cif · 2008-01-16 21:44:45

Cerebral wrote:

Cif wrote:
toofishes wrote:
Patches welcome.
Really? say it to Danimoth...
"Patches welcome" does not mean "we will apply each and every patch you ever send us" - it means that you're more than welcome to submit patches for things you think should be changed.

I hope that Danimoth's patch will be accepted...

shining · 2008-01-16 23:11:17

Cif wrote:

I hope that Danimoth's patch will be accepted...

You didn't even mention what patch you are talking about.
Do you mean this one : http://www.archlinux.org/pipermail/pacm … 10488.html ?

Now the only part that I need to code is the pacman-side.
Why I haven't coded this yet?
Because pacman-side is ( in my point of view ) the more difficult part,

Do you realize all the work left that needs to be done? The patch can't be accepted on its own, it's incomplete, and just the small part.
It might be interesting to see how well that works, but you need to implement the pacman side then.

But I believe Dan and Aaron are more interested by the tar backend idea anyway :
http://bugs.archlinux.org/task/8586

In any cases, why don't you have a look at all the open pacman bugs on flyspray, pacman-dev ML, and the TODO lists in pacman source tree to have a better idea of all the things that need to be done?
It's obvious we need priorities, and worry about fixing the more important stuff first. And then, the things that _we_ find important.
I hope that explains the "Patches welcome" better.

Caspian · 2008-01-16 23:29:47

I gave color output just as an example. But you must admit that color can come in handy while viewing big search results. It would also be very nice to have search for package description (similar to gentoo). One day , when job allows, i will look over pacman source and gladly try do help with some add ons. And guys, don't argue, this is after all Arch forum

ekerazha · 2008-01-16 23:34:03

Cerebral wrote:

Cif wrote:
Yeah... give pacman more speed... we're in 2008...
What's slow about pacman?

Pacman downloads a tar.gz archive (one for every repository) and unpacks it. Inside this archive there's a directory for every package and inside these dirs there are 3 text files: Pacman have to scan these dirs and then parse these files for every package... do you think this is efficient & fast? I don't think so.

Last edited by ekerazha (2008-01-16 23:40:37)

shining · 2008-01-17 00:07:19

Caspian wrote:

I gave color output just as an example. But you must admit that color can come in handy while viewing big search results. It would also be very nice to have search for package description (similar to gentoo). One day , when job allows, i will look over pacman source and gladly try do help with some add ons. And guys, don't argue, this is after all Arch forum

I agree that the search output is unreadable. But a simple bash script or function can fix that.
For example : http://projects.archlinux.org/git/?p=pa … /pacsearch

Otherwise, there is always the pacman-color package on AUR as I already mentioned.

About that search feature, you might want to make a feature request on flyspray. If it's clearly explained and defined, someone might want to implement it.

shining · 2008-01-17 00:09:33

ekerazha wrote:

Pacman downloads a tar.gz archive (one for every repository) and unpacks it. Inside this archive there's a directory for every package and inside these dirs there are 3 text files: Pacman have to scan these dirs and then parse these files for every package... do you think this is efficient & fast? I don't think so.

That's why there is a proposal of simply gunzip'ing the archive, and then working on that tar file.
http://bugs.archlinux.org/task/8586

ekerazha · 2008-01-17 10:33:39

shining wrote:

ekerazha wrote:
Pacman downloads a tar.gz archive (one for every repository) and unpacks it. Inside this archive there's a directory for every package and inside these dirs there are 3 text files: Pacman have to scan these dirs and then parse these files for every package... do you think this is efficient & fast? I don't think so.
That's why there is a proposal of simply gunzip'ing the archive, and then working on that tar file.
http://bugs.archlinux.org/task/8586

I know and this would be faster than the current solution (well... not so clean & good as a sqlite based backend), maybe the best thing you can do with the current "3 text files for every package" crap. However, some devs don't even like this idea.

mrB · 2008-01-17 10:50:01

How about adding simple strings for pacman's switches? I heard many newcomers complain that it was difficult to understand/remember pacman's switches. Is it possible to add alternate string commands witch basically do the same than -Syu, -Qs, -Ss etc?
For example:
pacman --add — the same as pacman -S

pacman --add-forced — the same as pacman -Sf

pacman --add-local — the same as pacman -U

pacman --clean-all — the same as pacman -Scc

pacman --download — the same as pacman -Sw

pacman --filelist — the same as pacman -Ql

pacman --info — the same as pacman -Si

pacman --installed — the same as pacman -Qs

pacman --list-inst-orphans — the same as pacman -Qdt

pacman --list-repo-orphans — the same as pacman -Qet

pacman --moreinfo — the same as pacman -Qi

pacman --provides — the same as pacman -Qo

pacman --remove — the same as pacman -R

pacman --remove-full — the same as pacman -Rs

pacman --remove-nodep — the same as pacman -Rd

pacman --search — the same as pacman -Ss

pacman --update — the same as pacman -Sy

pacman --upgrade-all — the same as pacman -Su

Allan · 2008-01-17 13:42:40

It already does that... look at "pacman --help" and e.g "pacman --sync --help".

Edit: I suppose they are not as "simple" though...

Last edited by Allan (2008-01-17 13:43:29)

mrB · 2008-01-17 14:47:08

Yeah you still need to type all the required tokens and the --sync part.

ahronzombi · 2008-01-17 15:23:39

use the pacman aur frontend yaourt if you want color.

fwojciec · 2008-01-17 15:31:03

mrB wrote:

How about adding simple strings for pacman's switches? I heard many newcomers complain that it was difficult to understand/remember pacman's switches. Is it possible to add alternate string commands witch basically do the same than -Syu, -Qs, -Ss etc?
For example:
pacman --add — the same as pacman -S
pacman --add-forced — the same as pacman -Sf
pacman --add-local — the same as pacman -U
pacman --clean-all — the same as pacman -Scc
pacman --download — the same as pacman -Sw
pacman --filelist — the same as pacman -Ql
pacman --info — the same as pacman -Si
pacman --installed — the same as pacman -Qs
pacman --list-inst-orphans — the same as pacman -Qdt
pacman --list-repo-orphans — the same as pacman -Qet
pacman --moreinfo — the same as pacman -Qi
pacman --provides — the same as pacman -Qo
pacman --remove — the same as pacman -R
pacman --remove-full — the same as pacman -Rs
pacman --remove-nodep — the same as pacman -Rd
pacman --search — the same as pacman -Ss
pacman --update — the same as pacman -Sy
pacman --upgrade-all — the same as pacman -Su

That would only make things more complex because it would duplicate terminology -- it would not be a KISS solution. Personally, I'd always prefer writing "pacman -Syu" than "pacman --upgrade-all" - it's just shorter and more transparent since each letter switch is meaningful and represents a particular functionality of pacman.

Arch Linux

#1 2008-01-16 11:19:07

Pacman evolution

#2 2008-01-16 14:30:49

Re: Pacman evolution

#3 2008-01-16 16:10:25

Re: Pacman evolution

#4 2008-01-16 17:10:57

Re: Pacman evolution

#5 2008-01-16 18:14:56

Re: Pacman evolution

#6 2008-01-16 18:56:44

Re: Pacman evolution

#7 2008-01-16 19:07:39

Re: Pacman evolution

#8 2008-01-16 19:27:41

Re: Pacman evolution

#9 2008-01-16 19:29:55

Re: Pacman evolution

#10 2008-01-16 19:30:16

Re: Pacman evolution

#11 2008-01-16 19:38:41

Re: Pacman evolution

#12 2008-01-16 19:51:22

Re: Pacman evolution

#13 2008-01-16 21:23:14

Re: Pacman evolution

#14 2008-01-16 21:44:45

Re: Pacman evolution

#15 2008-01-16 23:11:17

Re: Pacman evolution

#16 2008-01-16 23:29:47

Re: Pacman evolution

#17 2008-01-16 23:34:03

Re: Pacman evolution

#18 2008-01-17 00:07:19

Re: Pacman evolution

#19 2008-01-17 00:09:33

Re: Pacman evolution

#20 2008-01-17 10:33:39

Re: Pacman evolution

#21 2008-01-17 10:50:01

Re: Pacman evolution

#22 2008-01-17 13:42:40

Re: Pacman evolution

#23 2008-01-17 14:47:08

Re: Pacman evolution

#24 2008-01-17 15:23:39

Re: Pacman evolution

#25 2008-01-17 15:31:03

Re: Pacman evolution

Board footer