On Fri, Oct 21, 2016 at 11:06:04PM -0500, Doug Newgard wrote:
> On Sat, 22 Oct 2016 03:53:20 +
> Alive 4ever wrote:
>
> > On Fri, Oct 21, 2016 at 08:03:53PM +0200, Tinu Weber wrote:
> > Currently, pacman package includes a ``pacman-optimize`` script to do
> > manual periodic local database op
On 22/10/16 14:06, Alive 4ever wrote:
> On Sat, Oct 22, 2016 at 02:15:01AM +0800, Chi-Hsuan Yen via arch-general
> wrote:
>> On Sat, Oct 22, 2016 at 1:54 AM, Robin via arch-general <
>> arch-general@archlinux.org> wrote:
>>
>>> Hi,
>>>
I was curious why does 'pacman -Q' operations took longer
As the currently lead pacman developer... We will never have a sql (or
other) database backend.
When we did tests for the sync backends, using a single tar file gave
the same speed-up as using some sql variant (and we still have not
optimised any reading from that - for the sync "dbs", we always
On Sat, 22 Oct 2016 03:53:20 +
Alive 4ever wrote:
> On Fri, Oct 21, 2016 at 08:03:53PM +0200, Tinu Weber wrote:
> Currently, pacman package includes a ``pacman-optimize`` script to do
> manual periodic local database optimization.
Not for long.
https://git.archlinux.org/pacman.git/commit/?id
On Sat, Oct 22, 2016 at 02:15:01AM +0800, Chi-Hsuan Yen via arch-general wrote:
> On Sat, Oct 22, 2016 at 1:54 AM, Robin via arch-general <
> arch-general@archlinux.org> wrote:
>
> > Hi,
> >
> > > I was curious why does 'pacman -Q' operations took longer than 'apt'
> > > counterparts.
> > Sounds i
On Fri, Oct 21, 2016 at 08:03:53PM +0200, Tinu Weber wrote:
> On Fri, Oct 21, 2016 at 17:20:53 +, Alive 4ever wrote:
> > [...] It seems that the local pacman databases are just subdirectories
> > with text files (desc, files) and gzipped text (mtree).
> > No wonder why local pacman databases te
On Fri, Oct 21, 2016 at 11:44:42PM +0200, G. Schlisio wrote:
> optimisation ideas to the pacman database are (nearly) as old as this
> distribution, but none ever really convinced many.
> if you go back through the archives of the mailinglists and forums (as
> well as the outer parts of the interwe
> I was curious why does 'pacman -Q' operations took longer than 'apt'
> counterparts. It seems that the local pacman databases are just
> subdirectories with text files (desc, files) and gzipped text (mtree).
> No wonder why local pacman databases tend to slow down over time and
> need to be opti
On 10/21/2016 04:20 PM, David C. Rankin wrote:
> Arch devs,
>
> I'm receiving an error with KVM (arch guest). The guest installed fine from
> the 20161001 install media, but between every command, I receive the following
> error:
>
> [TTM] Byffer eviction failed
> qxl :00:02:0: object_init
Arch devs,
I'm receiving an error with KVM (arch guest). The guest installed fine from
the 20161001 install media, but between every command, I receive the following
error:
[TTM] Byffer eviction failed
qxl :00:02:0: object_init failed for (402650032, 0x0001)
[drm:qxl_alloc_bo_reserved [
Am 21.10.2016 um 21:48 schrieb Eli Schwartz via arch-general:
The reason pacman uses a flat file database as opposed to a relational
database, is the result of a deliberate design decision by the lead
pacman developers.
Therefore, I really really really doubt you will be able to convince
them to
On 10/21/2016 01:20 PM, Alive 4ever wrote:
> I was curious why does 'pacman -Q' operations took longer than 'apt'
> counterparts. It seems that the local pacman databases are just
> subdirectories with text files (desc, files) and gzipped text (mtree).
> No wonder why local pacman databases tend t
On Sat, Oct 22, 2016 at 1:54 AM, Robin via arch-general <
arch-general@archlinux.org> wrote:
> Hi,
>
> > I was curious why does 'pacman -Q' operations took longer than 'apt'
> > counterparts.
> Sounds interesting but I have a few question about how did you measure
> this and how big the difference
On Fri, Oct 21, 2016 at 17:20:53 +, Alive 4ever wrote:
> [...] It seems that the local pacman databases are just subdirectories
> with text files (desc, files) and gzipped text (mtree).
> No wonder why local pacman databases tend to slow down over time and
> need to be optimized periodically.
T
Hi,
> I was curious why does 'pacman -Q' operations took longer than 'apt'
> counterparts.
Sounds interesting but I have a few question about how did you measure this and
how big the difference is. (Shouldn't be that big). Would be great if you
provide more information on the comparability of yo
I was curious why does 'pacman -Q' operations took longer than 'apt'
counterparts. It seems that the local pacman databases are just
subdirectories with text files (desc, files) and gzipped text (mtree).
No wonder why local pacman databases tend to slow down over time and
need to be optimized peri
16 matches
Mail list logo
