Pacman evolution

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

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

You know, I tried to think of a nice way to say this, but I didn't get my coffee this morning.

That is a really stupid idea.

[edit] After seeing thist post, one of my colleagues recommended this for you: http://www.amazon.com/Ubuntu-Linux-Dumm … 0470125055

mrB · 2008-01-17 16:53:20

neotuli wrote:

You know, I tried to think of a nice way to say this, but I didn't get my coffee this morning.
That is a really stupid idea.
[edit] After seeing thist post, one of my colleagues recommended this for you: http://www.amazon.com/Ubuntu-Linux-Dumm … 0470125055

This isn't exactly for me; I have no problems with pacman's commands, I just think that sometimes things could be more intuitive. If you represent the whole team then your reaction proves how narrow-minded this community is.

jb · 2008-01-17 16:58:32

Here's the nice way to say it:

Although that may be a more intuitive way to handle pacman switches, it also adds a complexity with no gain to those who have no problem with command-line switches (which is the group Arch attempts to cater to).

Caspian · 2008-01-17 18:26:53

Ok guys take it easy. Meaning of this topic wasn't for us to argue all the time. Although i find this idea with switches quite stupid too. Then we might as well write something like: dear pacman will you please install a "package-name" with all dependencies for me

PJ · 2008-01-18 00:07:43

@mrB
I really don't like your idea and I don't think it will add anything usefull to pacman.

Anyway, I could mention that I am running kubuntu at work and I did actually wrote a wrapper bash script that handles arguments like pacman but it uses aptitude as the real package manager. I actually did this because I wrote to many pacman -Suy in kubuntu and I really couldn't get use to the syntax of apt-get/aptitude.

Here is a bash script that will work with your example arguments.

#!/bin/bash

case "$1" in

--add)
    shift
    pacman -S $@
    ;;

--add-forced)
    shift
    pacman -Sf $@
    ;;

--add-local)
    shift
    pacman -U $@
    ;;

--clean-all)
    shift
    pacman -Scc $@
    ;;

--download)
    shift
    pacman -Sw $@
    ;;

--filelist)
    shift
    pacman -Ql $@
    ;;

--info)
    shift
    pacman -Si $@
    ;;

--installed)
    shift
    pacman -Qs $@
    ;;

--list-inst-orphans)
    shift
    pacman -Qdt $@
    ;;

--list-repo-orphans)
    shift
    pacman -Qet $@
    ;;

--moreinfo)
    shift
    pacman -Qi $@
    ;;

--provides)
    shift 
    pacman -Qo $@
    ;;

--remove)
    shift
    pacman -R $@
    ;;

--remove-full)
    shift
    pacman -Rs $@
    ;;

--remove-nodep)
    shift
    pacman -Rd $@
    ;;

--search)
    shift
    pacman -Ss $@
    ;;

--update)
    shift
    pacman -Sy $@
    ;;

--upgrade-all)
    shift
    pacman -Su $@
    ;;

--help)
    echo "Need some help text here."
    ;;

*)
    pacman $@
    ;;

esac

shining · 2008-01-18 00:24:01

PJ wrote:

Here is a bash script that will work with your example arguments.

Heh, that's a good point A simple wrapper as a bash script does the job.

DaNiMoTh · 2008-01-18 12:42:05

Hello to all, I see that Cif has writed some unappropriated comment.. I think he doesn't understand some chatted talk

Actually, the point is that some developers hiding themselves behind "KISS" acronym. Sometimes, simple solutions aren't the most stupid...

An example, is the backend.
To keep it simple, is used a text-based database. Yes, is simple because any can look into /var/lib/pacman and see human-readable message.. but is stupid and wasteful. We're in 2008 and, luckily, some big mind have thought, theorized and written binary database, the most intelligent form of saving data ( uhu, I'm new on college world but the first thing that I'm studying is base of data ). But I'm not a troll like neotuli, so there is an explanation why text-based db ISN'T KISS.

Having text-based database for simple human-readable message, has complicated a lot pacman-code, with too many recursive function ( look into libalpm/be_files.c if you know C) in other words, pacman dev has needed to 'forge' another time the wheel.
Coding all these function, I think, isn't simple: and devs hard-fought this only for allowing users to see /var/lib/pacman. But NOBODY looks into /var/lib/pacman!
KISS ( Keep It Simple Stupid , where Stupid are you and not the thing that you need to do ) philosophy suggest re-use of code that is working well and do same things that you want, and in this case, SQLite is the code that we need. This is, finally, a simple solution! SQLite developers have done a great work, they work is public domain, and there is someone that prefer stupid things ( and not simple ).
I read too often 'patch are welcome'. I think it is like don't accept own responsibility.

Stop dreaming...

On my work, this is the algorithm:
- make big txt file, with all information cuncatenated;
- make index file, that contain byte seek of informations start and end;
- code pacman to use these 2 file.
The part that I need to do is the last. If anyone wants to help, would be great
I think it is the only way to improve pacman backend, at the actual situation.

ekerazha · 2008-01-18 14:18:03

Another "anti-sqlite" thesis is "we don't want external dependencies" "if we used external dependencies, we'd also use wget as file downloader".

Well... good point. Just some notes:

1) (one of) the first rule of open-source is do not reinvent the wheel
2) the second rule of open-source is DO NOT reinvent the wheel
3) a file downloader is quite easy to code
4) ... a decent database is NOT
5) sqlite is PUBLIC DOMAIN, well... you can copy/paste the sqlite code if you don't want external dependencies, but this is just stupid
6) current pacman database is inefficient, slow, crappy... there are too much scattered files around so it's also inefficient to backup while it's quite easy to corrupt something (I've already seen many corrupted pacman databases of #archlinux.it users)
7) one sqlite database is one file, it's elegant, fast, easy to manage and easy to backup... do you want a database backup? Just copy that single file over and over
8) If this is your first time here, you have to fight... oh wait... isn't this a fight club?

Last edited by ekerazha (2008-01-18 14:28:38)

chicha · 2008-01-18 16:14:18

I am quite new to Arch (about a year) and I am always surprised about this 'SQLite debate' which comes and comes again every few weeks.

I have read plainty of debates about this but nobody took the time to code a SQLite backend for Pacman to just demonstrate the marvelous gain people are expecting from SQLite.

Also SQLite is said to be the perfect tool for our needs. But what about other solutions, like BerkeleyDB which is much more simpler, whithout the need of any SQL related stuffs ? SQLite uses BerkeleyDB in background by the way ...
I feel like SQLite is a tank used to kill a fly in the case of Pacman's DB !

Anyway I am one of those who are happy to have a human readable DB : easy to read, easy to patch in case of problems, easy to implement advanced statistic/search tools ...

The best argument would be a patch to implement SQLite and a bench against the actual DB system.
Will the pro SQLite people manage to work together and prove they can implement a better DB ?

DaNiMoTh · 2008-01-18 17:08:15

chicha wrote:

I am quite new to Arch (about a year) and I am always surprised about this 'SQLite debate' which comes and comes again every few weeks.
I have read plainty of debates about this but nobody took the time to code a SQLite backend for Pacman to just demonstrate the marvelous gain people are expecting from SQLite.
Also SQLite is said to be the perfect tool for our needs. But what about other solutions, like BerkeleyDB which is much more simpler, whithout the need of any SQL related stuffs ? SQLite uses BerkeleyDB in background by the way ...
I feel like SQLite is a tank used to kill a fly in the case of Pacman's DB !

http://www.perl.com/pub/a/2004/09/12/embedded.html wrote:

There are situations when neither of the aforementioned straightforward access patterns applies. Berkeley DBs are great if we know the key for the record - but what happens if we only know part of the key, or we are interested in a set of records, all matching some pattern or logical expression? Alas, the Berkeley DB does not allow wildcard searches. Another frequently arising problem occurs when each record has several fields or attributes and we want to be able to look up records by either one of them (such as being able to search a list of books by author as well as title). This can be achieved in a Berkeley DB using multiple lookups, but one can't help thinking that there got to be a better way! Finally, the simple key/value mapping of the Berkeley DB occasionally forces duplication of data, since all the relevant information has to be present in each record - this both wastes storage space and creates maintenance problems.
Relational databases address all these points. They permit wildcard and logical expression searches, multiple searchable columns, and joins to represent relationships. Unfortunately, search capabilities such as these used to be restricted to big, standalone relational database engines (such as Postgres or Oracle), often making them unavailable for the quick-and-dirty Perl project.
This is where the SQLite project comes in: Founded in 2000, SQLite tries to combine the convenience of the Berkeley DB architecture with the power of a relational (SQL) database. Its latest release is version 2.8.14, with the next major revision, version 3.0, currently in beta. SQLite implements most of standard SQL (with some exceptions, such as correlated subqueries).

Pacman's DB isn't simple. Remember it.

Anyway I am one of those who are happy to have a human readable DB : easy to read, easy to patch in case of problems, easy to implement advanced statistic/search tools

Have you readed pacman's db? Why? Are you a friend of pacman? Sorry, I'm a human, the pacman's db need to be read from pacman ( I want go to play beachvolley instead )
Advanced statistic/search are easy to implement with whatever 'database' ( A "database" is an application that allows the targeted retrieval of stored data -- a log-file is not a database )

The best argument would be a patch to implement SQLite and a bench against the actual DB system.
Will the pro SQLite people manage to work together and prove they can implement a better DB ?

ekerazha wrote:

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).

So, if devs say "NO", we haven't time to waste.
Bench different backend is difficult, because it needs some modifications at repository.

Thanks to your post, I'm seriously motivated to write repo-side sqlite code, using the ekerazha functions and fork pacman. ( but before I need to talk with ekerazha )

shining · 2008-01-18 17:08:41

ekerazha wrote:

6) current pacman database is inefficient, slow, crappy... there are too much scattered files around so it's also inefficient to backup while it's quite easy to corrupt something (I've already seen many corrupted pacman databases of #archlinux.it users)

The idea is that when the db is corrupted, it might just be one file, which is not a big deal, and easy to fix.
What happens when a small part of your sqlite db get corrupted? Don't you lose everything?

7) one sqlite database is one file, it's elegant, fast, easy to manage and easy to backup... do you want a database backup? Just copy that single file over and over

man tar

phrakture · 2008-01-18 17:14:43

If someone disagrees with your ideas, they are shirking responsibility? I don't like this sort of name calling, let's stop it and try and be constructive please.

DaNiMoTh · 2008-01-18 17:30:22

chicha: http://archlinux.org/pipermail/pacman-d … 10278.html ( binary database for pacman, ignored by the mass )

To be costructive we need reassurance from archlinux's leader that, if SQLite ( or any other binary DB ) will work well, without problem ( or with the same problem of actual pacman, at least on the same level ), will be integrated and used in future release of pacman.

neotuli · 2008-01-18 17:50:40

This is where the SQLite project comes in: Founded in 2000, SQLite tries to combine the convenience of the Berkeley DB architecture with the power of a relational (SQL) database. Its latest release is version 2.8.14, with the next major revision, version 3.0, currently in beta. SQLite implements most of standard SQL (with some exceptions, such as correlated subqueries).

Can I get some use-cases for the pacman db needing relational db properties? I seem to be missing something, perhaps you can enlighten me.

Also, do you follow pacman-dev by any chance, since you are so passionate about these issues? If you did you'd know that this has been discussed before http://www.archlinux.org/pipermail/pacm … 06113.html , and that's a year and a half ago!
http://www.archlinux.org/pipermail/pacm … 09936.html , more recently! AND LOOK! ALL the pacman developers, even the Frugal guys, think it's best left the way it is!
http://bbs.archlinux.org/viewtopic.php?pid=244426 it has also been discussed numerous times on the bbs.
http://archlinux.org/pipermail/pacman-d … 10278.html - never even commented on by pacman developers, because it's been discussed before. And "ignored the the mass [sic]", because the guy that wrote it said it was just some proof-of-concept and not a serious attempt, of course it was ignored, he never intended it to be serious.
http://bbs.archlinux.org/viewtopic.php?t=10874 oh look it was discussed 3 years ago, before the current people even developed it.
.... and the list goes on.

so what i'm getting at here is that this has been being discussed for years now, and for years before you even joined the bbs, and no one has _ever_ indicated an interest in adding such features. Now I ask you, why the need to rediscuss the wheel? This has clearly been discussed before and yet you bring it up again as if after years of rejection, maybe the idea will catch on. I just don't get it.

nj · 2008-01-18 18:12:30

I don't really want a binary database due to corruption issues, but I'm always looking to improve my Python skills

import os
from sys import argv
import re

p = argv[1]

class Pkg:
    pass

print 'begin;'
print 'create table packages ('
print 'id int,'
print 'name varchar(255),'
print 'filename varchar(255),'
print 'desc varchar(255),'
print 'url varchar(255),'
print 'arch varchar(255),'
print 'builddate varchar(255),'
print 'installdate varchar(255),'
print 'packager varchar(255),'
print 'reason varchar(255),'
print 'size varchar(255),'
print 'csize varchar(255),'
print 'isize varchar(255),'
print 'md5sum varchar(255));'

print 'create table groups (name varchar(255), package int);'
print 'create table license (name varchar(255), package int);'
print 'create table replaces (name varchar(255), package int);'

desc_fields = (
        ('filename', str),
        ('desc', str),
        ('groups', list),
        ('url', str),
        ('license', list),
        ('arch', str),
        ('builddate', str),
        ('installdate', str),
        ('packager', str),
        ('reason', int),
        ('size', int),
        ('csize', int),
        ('isize', int),
        ('md5sum', str),
        ('replaces', list),
)

def get_oneline(f, line, string, setter):
    if line.startswith(string):
        setter(f.readline().strip())

def get_list(f, line, string, setter):
    if line.startswith(string):
        while 1:
            l = f.readline().strip()
            if len(l) == 0:
                break
            setter(l)

dirs = [p+'/'+d for d in os.listdir(p) if os.path.isdir(p+'/'+d)]
files = [fn+'/desc' for fn in dirs if os.path.isfile(fn+'/desc')]

pkgs = []

r = re.compile('/var/lib/pacman/sync/[^/]+/+(.*)-.*-.*/desc')

for filename in files:
    f = open(filename)

    pkg = Pkg()
    for (field, func) in desc_fields:
        setattr(pkg, field, func())

    pkg.name = r.match(filename).groups()[0]

    while 1:
        line = f.readline()
        if len(line) == 0:
            break

        for (field, func) in desc_fields:
            if func is list:
                get_list(f, line, '%' + field.upper() + '%', lambda x: getattr(pkg, field).append(x))
            else:
                get_oneline(f, line, '%' + field.upper() + '%', lambda x: setattr(pkg, field, func(x)))

    pkgs.append(pkg)

    f.close()

id = 0
fields = [f for (f,u) in desc_fields if u is not list]
for pkg in pkgs:
    id += 1
    print 'insert into packages (id, name, ' + ', '.join(fields) + ') values (' + str(id) + ", '" + pkg.name + "',",
    vals = ["'"+str(getattr(pkg, field)).replace("'", "")+"'" for field in fields]
    print ', '.join(vals) + ');'

    for i in pkg.groups:
        print "insert into groups (name, package) values ('" + i + "', " + str(id) + ");"

    for i in pkg.license:
        print "insert into license (name, package) values ('" + i + "', " + str(id) + ");"

    for i in pkg.replaces:
        print "insert into replaces (name, package) values ('" + i + "', " + str(id) + ");"

print 'commit;'

$ python sqlize.py /var/lib/pacman/sync/extra/ | sqlite3 extra.db

$ lh extra.db
-rw-r--r-- 1 nathanj users 341K 2008-01-18 12:54 extra.db

$ time sqlite3 extra.db "select name from packages where desc like '%opera%'"
syslinux
xdrawchem
patchutils
opera
sqlite3 extra.db 0.01s user 0.01s system 114% cpu 0.012 total

$ time sqlite3 extra.db "select packages.name from groups, packages where package = id and groups.name = 'gnome'"
libgail-gnome
metacity
gnome-control-center
gnome-applets
epiphany
gnome-desktop
gnome-media
nautilus
gnome-mount
gnome-themes
gnome2-user-docs
gnome-session
gnome-panel
gnome-icon-theme
gnome-backgrounds
gnome-mime-data
yelp
sqlite3 extra.db   0.02s user 0.00s system 90% cpu 0.030 total

ekerazha · 2008-01-18 19:46:25

shining wrote:

ekerazha wrote:
6) current pacman database is inefficient, slow, crappy... there are too much scattered files around so it's also inefficient to backup while it's quite easy to corrupt something (I've already seen many corrupted pacman databases of #archlinux.it users)
The idea is that when the db is corrupted, it might just be one file, which is not a big deal, and easy to fix.
What happens when a small part of your sqlite db get corrupted? Don't you lose everything?

This is probability: if I have 1 file, I have 1 file that could be corrupted... if you have 1000 text file, you have 1x1000 chances of corruption. Using 1 file I have highest chances of a "destructive" corruption (because it's all inside 1 file) however, as I've already said, if I have 1 file I can easily and efficiently copy that single file over and over and over and I've every time *complete* backups.

Obvious... add this to the better performances and flexibility of a sqlite based approach.

7) one sqlite database is one file, it's elegant, fast, easy to manage and easy to backup... do you want a database backup? Just copy that single file over and over
man tar

Oh yeah... un-tar and tar, un-tar and tar, un-tar and tar... this is SO clean & efficient baby a good addon to the already efficient backend of pacman

Last edited by ekerazha (2008-01-18 19:48:07)

ekerazha · 2008-01-18 19:57:15

neotuli wrote:

This is where the SQLite project comes in: Founded in 2000, SQLite tries to combine the convenience of the Berkeley DB architecture with the power of a relational (SQL) database. Its latest release is version 2.8.14, with the next major revision, version 3.0, currently in beta. SQLite implements most of standard SQL (with some exceptions, such as correlated subqueries).
Can I get some use-cases for the pacman db needing relational db properties? I seem to be missing something, perhaps you can enlighten me.
Also, do you follow pacman-dev by any chance, since you are so passionate about these issues? If you did you'd know that this has been discussed before http://www.archlinux.org/pipermail/pacm … 06113.html , and that's a year and a half ago!
http://www.archlinux.org/pipermail/pacm … 09936.html , more recently! AND LOOK! ALL the pacman developers, even the Frugal guys, think it's best left the way it is!
http://bbs.archlinux.org/viewtopic.php?pid=244426 it has also been discussed numerous times on the bbs.
http://archlinux.org/pipermail/pacman-d … 10278.html - never even commented on by pacman developers, because it's been discussed before. And "ignored the the mass [sic]", because the guy that wrote it said it was just some proof-of-concept and not a serious attempt, of course it was ignored, he never intended it to be serious.
http://bbs.archlinux.org/viewtopic.php?t=10874 oh look it was discussed 3 years ago, before the current people even developed it.
.... and the list goes on.
so what i'm getting at here is that this has been being discussed for years now, and for years before you even joined the bbs, and no one has _ever_ indicated an interest in adding such features. Now I ask you, why the need to rediscuss the wheel? This has clearly been discussed before and yet you bring it up again as if after years of rejection, maybe the idea will catch on. I just don't get it.

SQLite: SELECT * FROM foo_bar WHERE group = 'gnome'

Do you think this is slower than the current <scan dirs on filesystem, then parse every text file and look if the group is 'gnome'> ?

I've already read every discussion on sqlite and who think the sqlite approach is worse than the current approach is just wrong: most reasons I've read are ridiculous (makes me laugh hehehe very funny). Uh... and point 1: as I've already said, SQLite isn't daemon based like MySQL or PostgreSQL (as a dev believed).

Last edited by ekerazha (2008-01-18 19:58:21)

shining · 2008-01-18 19:58:14

ekerazha wrote:

This is probability: if I have 1 file, I have 1 file that could be corrupted... if you have 1000 text file, you have 1x1000 chances of corruption. Using 1 file I have highest chances of a "destructive" corruption (because it's all inside 1 file) however, as I've already said, if I have 1 file I can easily and efficiently copy that single file over and over and over and I've every time *complete* backups.

You might be forgetting that these files don't exactly have the same size.

Oh yeah... un-tar and tar, un-tar and tar, un-tar and tar... this is SO clean & efficient baby a good addon to the already efficient backend of pacman

Well you can un-tar and tar all the time, if you find that fun. Or you could simply tar it.
You make it sound like you break your database and restore it every day.

ekerazha · 2008-01-18 20:03:56

shining wrote:

ekerazha wrote:
This is probability: if I have 1 file, I have 1 file that could be corrupted... if you have 1000 text file, you have 1x1000 chances of corruption. Using 1 file I have highest chances of a "destructive" corruption (because it's all inside 1 file) however, as I've already said, if I have 1 file I can easily and efficiently copy that single file over and over and over and I've every time *complete* backups.
You might be forgetting that these files don't exactly have the same size.

1) one file is easy to copy independently from its size.
2) this binary approach is already more "size optimized"
3) I can enable "native" compression on sqlite databases (linking zlib)

Oh yeah... un-tar and tar, un-tar and tar, un-tar and tar... this is SO clean & efficient baby a good addon to the already efficient backend of pacman
Well you can un-tar and tar all the time, if you find that fun. Or you could simply tar it.
You make it sound like you break your database and restore it every day.

"One" day (when you don't expect it) is enough.

shining · 2008-01-18 20:25:33

ekerazha wrote:

SQLite: SELECT * FROM foo_bar WHERE group = 'gnome'
Do you think this is slower than the current <scan dirs on filesystem, then parse every text file and look if the group is 'gnome'> ?
I've already read every discussion on sqlite and who think the sqlite approach is worse than the current approach is just wrong: most reasons I've read are ridiculous (makes me laugh hehehe very funny). Uh... and point 1: as I've already said, SQLite isn't daemon based like MySQL or PostgreSQL (as a dev believed).

Then why are you still discussing it, instead of finishing your patch and showing us some result?
You even have a python script now for converting your sync db to sqlite thanks to nj.
Even if your patch wasn't accepted, you could always use it for you. For example, incorporate the above python script or an equivalent to the -Sy operation, so that your sync dbs could be converted automatically. And your local db needs to be converted just once.

ekerazha · 2008-01-18 20:36:37

shining wrote:

ekerazha wrote:
SQLite: SELECT * FROM foo_bar WHERE group = 'gnome'
Do you think this is slower than the current <scan dirs on filesystem, then parse every text file and look if the group is 'gnome'> ?
I've already read every discussion on sqlite and who think the sqlite approach is worse than the current approach is just wrong: most reasons I've read are ridiculous (makes me laugh hehehe very funny). Uh... and point 1: as I've already said, SQLite isn't daemon based like MySQL or PostgreSQL (as a dev believed).
Then why are you still discussing it, instead of finishing your patch and showing us some result?
You even have a python script now for converting your sync db to sqlite thanks to nj.
Even if your patch wasn't accepted, you could always use it for you. For example, incorporate the above python script or an equivalent to the -Sy operation, so that your sync dbs could be converted automatically. And your local db needs to be converted just once.

Because, as I've already said, using a sqlite approach only for the [local] database is just stupid. It makes sense especially if the remote databases are sqlite based too. Do you think I'll make a complete patch (I had already partially written it) risking that Arch devs will say "no, we won't change remote databases"? I'm a computer engineering student and just like every engineering student I'm *very* busy. I can complete that patch if they say "when we will have the patch, we will change the remote databases format", I really *can't* waste my time vainly.

phrakture · 2008-01-18 22:44:47

Let's stop arguing... this is dumb. If we're all "so busy" let's go be busy elsewhere where we're not broaching topics that have been touched on throughout my entire stay with ArchLinux and people have still to do anything about

wain · 2008-01-18 23:50:25

I totally agree with Vmiklos. Maybe a single file for sync dbs (or one for each repository) could be fine, but local db must stay as this.

ekerazha · 2008-01-19 01:38:01

phrakture wrote:

Let's stop arguing... this is dumb. If we're all "so busy" let's go be busy elsewhere where we're not broaching topics that have been touched on throughout my entire stay with ArchLinux and people have still to do anything about

Please reply to this (if you want):

SQLite: SELECT * FROM foo_bar WHERE group = 'gnome'
Do you think this is slower than the current <scan dirs on filesystem, then parse every text file and look if the group is 'gnome'> ?

People will "do" when the things to "do" will be understood and accepted, people won't waste their time vainly because some people don't (want to) understand.

Last edited by ekerazha (2008-01-19 01:50:32)

Allan · 2008-01-19 01:52:17

ekerazha wrote:

People will "do" when the things to "do" will be understood and accepted, people won't waste their time vainly.

Well, take a lesson from the Arch Stable guys. The devs had seen the idea many, many times but it was in the "no time" or "not the Arch way" basket. So finally, a group has actually started doing something about it. Why don't the people who want a database backend create a patch-set to implement it. If people think it is a good idea and the speed-up is noticeable, then people will use it. If it is a complete solution, it may even be considered by the devs. Even if not, you can always supply a pacman-sqlite package that replaces and provided pacman.

Last edited by Allan (2008-01-19 01:53:41)

Arch Linux

#26 2008-01-17 16:10:35

Re: Pacman evolution

#27 2008-01-17 16:53:20

Re: Pacman evolution

#28 2008-01-17 16:58:32

Re: Pacman evolution

#29 2008-01-17 18:26:53

Re: Pacman evolution

#30 2008-01-18 00:07:43

Re: Pacman evolution

#31 2008-01-18 00:24:01

Re: Pacman evolution

#32 2008-01-18 12:42:05

Re: Pacman evolution

#33 2008-01-18 14:18:03

Re: Pacman evolution

#34 2008-01-18 16:14:18

Re: Pacman evolution

#35 2008-01-18 17:08:15

Re: Pacman evolution

#36 2008-01-18 17:08:41

Re: Pacman evolution

#37 2008-01-18 17:14:43

Re: Pacman evolution

#38 2008-01-18 17:30:22

Re: Pacman evolution

#39 2008-01-18 17:50:40

Re: Pacman evolution

#40 2008-01-18 18:12:30

Re: Pacman evolution

#41 2008-01-18 19:46:25

Re: Pacman evolution

#42 2008-01-18 19:57:15

Re: Pacman evolution

#43 2008-01-18 19:58:14

Re: Pacman evolution

#44 2008-01-18 20:03:56

Re: Pacman evolution

#45 2008-01-18 20:25:33

Re: Pacman evolution

#46 2008-01-18 20:36:37

Re: Pacman evolution

#47 2008-01-18 22:44:47

Re: Pacman evolution

#48 2008-01-18 23:50:25

Re: Pacman evolution

#49 2008-01-19 01:38:01

Re: Pacman evolution

#50 2008-01-19 01:52:17

Re: Pacman evolution

Board footer