IRC Logs for #crux-devel Tuesday, 2019-11-26

*** posixmeharder has joined #crux-devel04:07
ryuojaeger: you mentioned wanted to try a new DB format or adding extra metadata? what else could be stored? pkgutils doesn't track dependencies.04:22
ryuonot sure what else it could store.04:22
ryuoi guess it could store stuff to make revdep more efficient like elf SO information.04:23
jaegermy version would store deps, implicit and explicit, as well as metadata like when it was originally installed, maybe previous version, stuff like that05:04
ryuojaeger: i see. i think berkeley db might work.06:12
ryuoonly db currently in core.06:12
tnutHi frinnst ;)10:32
tnutjaeger ryuo : might be a source of inspiration of news ideas (fork of pkgutils)10:38
tnutMy only recommandation: don't add any unecessary dependencies in pkgutils (like a db)10:40
*** chinarulezzz has joined #crux-devel10:54
*** chinarulezzz has quit IRC11:24
*** pedja has joined #crux-devel12:23
*** chinarulezzz has joined #crux-devel12:56
stenurOr use lmdb which is 450KB source without doc+test, 960 KB installed.13:09
stenurFree license, stable (if you care), from LDAP project. Very fast.13:09
tnutI think using an external db for pkgutils is overkill. Not sure it's the aim of this distro.13:30
tnutby the way deps are not manage by pkgutils so they cannot be much metadata to store beside name, version, release (all the others are ..comments in a crux recept, including deps)13:32
stenurThat "if you care" referred to lmdb initialization issues (i can make it crash)13:45
stenur(This is why my bogofilter lmdb backend is actually two. But the cool one was chosen.)13:46
jaegerI haven't gotten to the point of figuring out the metadata yet, I was working on just feature parity first with the rewrite14:37
jaegerwasn't planning to use a db or add deps, though14:37
jaegerat least not immediately. Maybe in the future if the benefit was significant14:37
tnutI guess the only relevant metadata for pkgutils would be the description of the package14:42
*** chinarulezzz has quit IRC14:47
ryuopart of the problem is the existing database cannot be extended.18:05
ryuoso if i did add a new one, it would haveto be a format that can be arbitrarily extended.18:05
jaegerMy tentative plan was to add separate metadata files or a central metadata file like the current db18:06
jaegerHaven't explored it yet, though18:06
ryuojaeger: i was thinking something like JSON files. they can't be parsed by AWK but they do have plenty of tools that can read them.18:07
ryuothey're arbitrarily extended, fairly low structure overhead.18:07
jaegeryeah, I considered that as well18:10
ryuoi'd prefer to keep a monolithic DB file myself. it makes transactions a lot easier to code.19:08
frinnstjaeger & jue: thoughts about doing a release soonish defaulting to python3?19:49
frinnstpretty much everything can be replaced. just a lot of footprint shit needing dealing with19:49
*** pedja has quit IRC19:53
*** pedja has joined #crux-devel19:53
ryuofrinnst, jaeger, jae: i had an idea or a replacement DB format for pkgutils. we could use the debian style text file format. it use key value pairs per line to allow for infinite expandability of field options and also allows multiline fields. thoughts?21:43
*** pedja has quit IRC22:10
*** Workster has joined #crux-devel22:32
ryuoexample of one package:
ryuoeither way i think a new DB format is in order in the long run.23:59
ryuoone that can be expanded indefinitely.23:59
ryuothe current one can only record the same fixed data as it originally did.23:59

Generated by 2.14.0 by Marius Gedminas - find it at!