[pacman-dev] [PATCH] pmdb_t: allow repo names to be longer than 128 chars
hi http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=plain_commitdif...; any reason for limiting the length of the repo names? i would suggest increase the limit to PATH_MAX udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
VMiklos wrote:
hi
http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=plain_commitdif...;
any reason for limiting the length of the repo names? i would suggest increase the limit to PATH_MAX
PATH_MAX is usually 4096 bytes, which is quite huge compared to the actual needs. DB_TREENAME_LEN is 128 bytes which is already ways too much (64 or even 32 would be enough): treename is only a directory name and not a complete path (like root+dbpath+treename). I concede the library is not manipulating lots of pmdb_t structs, but I don't see the need to increase by about 4Kb the size of each instance of it. BTW, I was even thinking to reduce the memory footprint of pacman by using shorter fields in the pmpkg_t struct. For instance, 512 bytes is quite big for the package description length, whereas the package guidelines are recommending 80 bytes at most. Knowing that there are about 1700 packages in extra, it means loading the cache will allocate 1700*512=870Kb (only for package descriptions!!!), whereas maybe only 1700*100=170Kb are actually needed. I think it would be interesting to collect statistics of fields length from packages in our repositories in order to fine tune the pmpkg_t structure fields size (mainly for name, version, desc, url and packager)... Or we may use dynamically allocated fields, if it does not slow down the library too much... -- Aurelien
On Tue, Mar 21, 2006 at 10:42:37PM +0100, Aurelien Foret <aurelien@archlinux.org> wrote:
I think it would be interesting to collect statistics of fields length from packages in our repositories in order to fine tune the pmpkg_t structure fields size (mainly for name, version, desc, url and packager)...
Or we may use dynamically allocated fields, if it does not slow down the library too much...
the new project: pacbench :-) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
participants (2)
-
Aurelien Foret
-
VMiklos