2016/10/23 20:42、Alive 4ever のメッセージ:
>> On Sun, Oct 23, 2016 at 01:57:23AM -0400, Eli Schwartz via arch-general
>> wrote:
>> On 10/23/2016 01:41 AM, Alive 4ever wrote:
Also consider the fact that your pacman database is one of the least
likely pieces of data to target for the sake of
On Sun, Oct 23, 2016 at 01:57:23AM -0400, Eli Schwartz via arch-general wrote:
> On 10/23/2016 01:41 AM, Alive 4ever wrote:
> >> Also consider the fact that your pacman database is one of the least
> >> likely pieces of data to target for the sake of noticeably improving
> >> your computer's overal
Op 21 okt. 2016 21:49 schreef "Eli Schwartz via arch-general" <
arch-general@archlinux.org>:
>
> On 10/21/2016 01:20 PM, Alive 4ever wrote:
> [...] road map, it would be better to use
> > single sql based database for tracking locally installed packages
>
> The reason pacman uses a flat file databa
On 10/23/2016 01:41 AM, Alive 4ever wrote:
>> Also consider the fact that your pacman database is one of the least
>> likely pieces of data to target for the sake of noticeably improving
>> your computer's overall performance.
>>
>
> Yeah, I am aware of it. Hardware components tend to degrade over
On Sat, Oct 22, 2016 at 08:35:15PM -0400, Eli Schwartz via arch-general wrote:
> Right... but if you look at the stated reason for its removal, you tend
> to get the impression that the lead pacman developer is actually
> explicitly calling you (rhet.) a blithering idiot if you (rhet.) think
> that
On 10/22/2016 02:28 AM, Alive 4ever wrote:
> 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`` scr
On Sat, 22 Oct 2016 04:06:31 +
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 '
On Sat, Oct 22, 2016 at 02:20:30PM +1000, Allan McRae wrote:
> 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 h
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
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
22 matches
Mail list logo