Maybe this is a better place where discuss this (
http://bbs.archlinux.org/viewtopic.php?id=42374 ) or at least I've have
to clarify some things.

1)**

toofishes says:
------------------------------------------------------------------------
Yes its faster. But does it matter all that much?

$ time pacman -Qg gnome > /dev/null

real 0m0.105s
user 0m0.047s
sys 0m0.037s

$ time pacman -Sg gnome > /dev/null

real 0m0.388s
user 0m0.160s
sys 0m0.203s

------------------------------------------------------------------------

Well... these are my results with Pacman 3.1.0 (Pentium III 933 Mhz,
PC133 512 MB, 120 GB 7200rpm with XFS filesystem, "pacman-optimize"
regularly done):

[root@PC-ekerazha ekerazha]# time pacman -Qg gnome > /dev/null

real 0m8.083s
user 0m0.107s
sys 0m0.233s

[root@PC-ekerazha ekerazha]# time pacman -Sg gnome > /dev/null

real 0m44.482s
user 0m0.510s
sys 0m0.963s

So 8 and 44 seconds (44 seconds!). Apparently it really matters...

toofishes says:
------------------------------------------------------------------------
Here are the things to "do" since you don't seem to understand we are
"busy" developing "software" that works and doesn't "break" people's
systems in the "name" of speed.
------------------------------------------------------------------------

Why should the sqlite approach "break people's systems in the name of
speed"? You clearly don't know what are you talking about... I really
hope there are also competent pacman devs there (as you say).

2)

phrakture,
people like "toofishes" is the living example of why "show you the code"
(already partially done but incomplete) is useless. As I've already
said, <People will "do" when the things to "do" will be *understood and
accepted*, people won't waste their time vainly> and it seems obvious
that people like "toofishes" isn't understanding anything about this.

However... keep up the good work because Arch is a great Linux distro
(the best out there) and well... pacman is a "decent" package manager
(although poorly engineered and very slow).

P.S.
Excuse me for my bad English but it isn't my native language.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Uh... I was forgetting this thing...

toofishes says:
------------------------------------------------------------------------
I didn't know utilizing the kernel cache was against the law.
------------------------------------------------------------------------

I didn't know the cache was *always* populated... what about the "44
seconds"?

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

On Sat, 19 Jan 2008 11:35:08 +0100
"Manuel "ekerazha" C." <manuel@ekerazha.com> wrote:
> [cut]

I don't want to troll there, only one suggestion ( then I go to write
some code ):

Effectively, pacman needs 40 seconds to perform a search.. using kernel
cache is a workaround. Isn't against any law, but using it is
equivalent to hide pacman inefficiency.

--
JJDaNiMoTh - ArchLinux Trusted User
_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

JJDaNiMoTh wrote:
> On Sat, 19 Jan 2008 11:35:08 +0100
> "Manuel "ekerazha" C." <manuel@ekerazha.com> wrote:
>> [cut]
>
> I don't want to troll there, only one suggestion ( then I go to write
> some code ):
>
> Effectively, pacman needs 40 seconds to perform a search.. using kernel
> cache is a workaround. Isn't against any law, but using it is
> equivalent to hide pacman inefficiency.
>

Hi everybody, I agree with JJDaNiMoTh.
Here some tests on my machine too:

[root /home/giuseppe ]# sync; echo 3 > /proc/sys/vm/drop_caches
[root /home/giuseppe ]# time pacman -Qi > /dev/null

real 0m17.745s [not cached]
user 0m1.057s
sys 0m1.107s
[root /home/giuseppe ]# time pacman -Qi > /dev/null

real 0m1.166s [cached]
user 0m1.017s
sys 0m0.120s

---

[root /home/giuseppe ]# sync; echo 3 > /proc/sys/vm/drop_caches
[root /home/giuseppe ]# time pacman -Qg gnome > /dev/null

real 0m8.944s [not cached]
user 0m0.117s
sys 0m0.840s
[root /home/giuseppe ]# time pacman -Qg gnome > /dev/null

real 0m0.216s [cached]
user 0m0.127s
sys 0m0.063s

---

Tests done on a Asus A7D notebook.

Regards,
Giuseppe


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

> toofishes says:
> ------------------------------------------------------------------------
> Here are the things to "do" since you don't seem to understand we are
> "busy" developing "software" that works and doesn't "break" people's
> systems in the "name" of speed.
> ------------------------------------------------------------------------
>
> Why should the sqlite approach "break people's systems in the name of
> speed"? You clearly don't know what are you talking about... I really
> hope there are also competent pacman devs there (as you say).

I think this was discussed many times here, why we prefer the current backend:
Simply because we are paranoid; we afraid of the following "message":
"~Database is corrupted, restore it from backup", and we got a cryptic bunch of
bytes as database.
Saying not competent just because he doesn't agree with you is not a good
argument. Well, probably we are not dbms experts, so instead of flaming you
should convince us, why using your method is safe.

I add one argument here: maybe using a professional dbms would reduce memory
usage; but I am incompenent here, indeed ;-)

Bye


----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

> I think this was discussed many times here, why we prefer the current backend:
> Simply because we are paranoid; we afraid of the following "message":
> "~Database is corrupted, restore it from backup", and we got a cryptic bunch of
> bytes as database.
> Saying not competent just because he doesn't agree with you is not a good
> argument. Well, probably we are not dbms experts, so instead of flaming you
> should convince us, why using your method is safe.
>
> I add one argument here: maybe using a professional dbms would reduce memory
> usage; but I am incompenent here, indeed ;-)

Did you read the bbs thread I linked before? ;-)
( http://bbs.archlinux.org/viewtopic.php?id=42374 )


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

Wanted to get some relevant linkage in this thread:

http://www.archlinux.org/pipermail/pacman-dev/2006-October/006113.html
http://www.archlinux.org/pipermail/pacman-dev/2007-November/009936.html
http://www.archlinux.org/pipermail/pacman-dev/2007-November/010278.html

I am going to try really hard to keep this civil in here, so please do
the same. I post the above links for this reason- this idea has come
up many times before. And every time it doesn't seem to catch the
attention of our devs. To find out why, you are going to have to do
some reading of the above threads.

This is not to say it can't be done. I just don't think those of us
that are currently coding a lot of things for pacman find this to be a
priority or a big problem in our minds, and/or think there are other
ways to better solve the problem, such as reading straight from a
tar.gz database which libarchive makes *really* easy, but the current
pacman code needs some work to support. I would be very interested in
working on a refactoring so that multiple backends could be possible-
the code as it currently stands makes that awfully hard.

-Dan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

> Wanted to get some relevant linkage in this thread:
>
> http://www.archlinux.org/pipermail/pacman-dev/2006-October/006113.html
> http://www.archlinux.org/pipermail/pacman-dev/2007-November/009936.html
> http://www.archlinux.org/pipermail/pacman-dev/2007-November/010278.html
>
> I am going to try really hard to keep this civil in here, so please do
> the same. I post the above links for this reason- this idea has come
> up many times before. And every time it doesn't seem to catch the
> attention of our devs. To find out why, you are going to have to do
> some reading of the above threads.
>
> This is not to say it can't be done. I just don't think those of us
> that are currently coding a lot of things for pacman find this to be a
> priority or a big problem in our minds, and/or think there are other
> ways to better solve the problem, such as reading straight from a
> tar.gz database which libarchive makes *really* easy, but the current
> pacman code needs some work to support. I would be very interested in
> working on a refactoring so that multiple backends could be possible-
> the code as it currently stands makes that awfully hard.

As I've already pointed out inside the previous linked thread
( http://bbs.archlinux.org/viewtopic.php?id=42374 ) I've already read
all the previous "sqlite" discussions.

What about the "libarchive" way? Well... it IS a step forward compared
to the current backend. I think this is still worse than a sqlite based
approach however it IS definitely a good improvement.


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

On Jan 19, 2008 10:28 AM, Manuel ekerazha C. <manuel@ekerazha.com> wrote:
>
> > Wanted to get some relevant linkage in this thread:
> >
> > http://www.archlinux.org/pipermail/pacman-dev/2006-October/006113.html
> > http://www.archlinux.org/pipermail/pacman-dev/2007-November/009936.html
> > http://www.archlinux.org/pipermail/pacman-dev/2007-November/010278.html
> >
> > I am going to try really hard to keep this civil in here, so please do
> > the same. I post the above links for this reason- this idea has come
> > up many times before. And every time it doesn't seem to catch the
> > attention of our devs. To find out why, you are going to have to do
> > some reading of the above threads.
> >
> > This is not to say it can't be done. I just don't think those of us
> > that are currently coding a lot of things for pacman find this to be a
> > priority or a big problem in our minds, and/or think there are other
> > ways to better solve the problem, such as reading straight from a
> > tar.gz database which libarchive makes *really* easy, but the current
> > pacman code needs some work to support. I would be very interested in
> > working on a refactoring so that multiple backends could be possible-
> > the code as it currently stands makes that awfully hard.
>
> As I've already pointed out inside the previous linked thread
> ( http://bbs.archlinux.org/viewtopic.php?id=42374 ) I've already read
> all the previous "sqlite" discussions.

You clearly have not thought about them then. Stop linking the BBS here please.

> What about the "libarchive" way? Well... it IS a step forward compared
> to the current backend. I think this is still worse than a sqlite based
> approach however it IS definitely a good improvement.

OK. Since you didn't seem to want to help me with refactoring, I'll do
my thing and you do yours. Best of luck!

-Dan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev

> You clearly have not thought about them then. Stop linking the BBS here please.

Well... most of the "anti sqlite" arguments inside that linked pages are
just ridicoulous and YES, I've already replied to them inside the BBS
page I linked before.

> OK. Since you didn't seem to want to help me with refactoring, I'll do
> my thing and you do yours. Best of luck!

Good luck with your ideas, Dan!


_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev