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 overall performance.
> >>
> >
> > Yeah, I am aware of it. Hardware components tend to degrade over time,
> > especially mechanical hard drive.
>
> What part of "least likely pieces of *data*" was not obvious enough in
> its reference to *data*, such that you felt the need to conflate data
> with hardware?
>
> If you are agreeing with me ("Yeah, I am aware of it") then stop
> mentioning hardware.
> If you are arguing with me, then please explain what you actually meant
> to say and what it has to do with hardware.
>
> ...
Back to the subject, I wanted to propose my idea on how to speed up
pacman local database access - regardless of the hardware.
Some folks replied with something like ``there is no need for this, just
go get an ssd``, which is misleading.
I post the idea here as suggestion for pacman local database improvement,
not as complaint on slow filesystem access on mechanical drive.
>
> I am still pretty sure that whatever problem you may have, it is not
> pacman-specific and it doesn't require a pacman-specific tool.
>
> So while you might disagree with the political commentary invoked in
> that commit message, the general idea that the script is a waste of
> space is something I can get behind!
While using sql for pacman database could potentially provide faster
access to local database, there is a risk of database corruption that
isn't easy to recover. Current approach of using smaller files for
databases also has its own advantage as gsnijder explained.
> One really big advantage of this approach is that you don't have to worry
> about corrupted databases. It's been a while since I used an RPM based
> distro, but it always surprised me how quickly the db would fall over and
> needed to be rebuilt.
> The beauty of the Arch approach is it's robust simplicity. And yes, there
> are/were wrappers that use a SQL DB for specific operations. If such a db
> gets problems, there is nothing to worry about: pacman just keeps working
> anyway.
I'll leave it to developers to take whichever methods for pacman local
database.
