Pacman issues...

test1000 · 2006-01-22 02:05:24

1. has there been any discussion about whether pacman should be allowed to make pkgbuild with package.install which compiles itself when the *.install is ran (like pacman -A moopackage.pkg.tar.gz); this would be awesome for kernel modules! blablabla ofctaoe

2. while doing this search: http://www.google.com/search?client=ope … 8&oe=utf-8

some links states that there are faster solutions than sqlite.. i just thought it would be interesting to the devs for obvious reasons concerning pacman 3..

3. i forget..

Moderator Note:
I guess we don't need two posts? Below copied from a post unusefully titled 'more'

ok guys; maybe i was a bit unclear? so i just post my irc logs(i just grepped my name and iamsthitha) to try and aid to the confusing:

.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 02:56:36 nut543 has there been any discussion about whether it should be allowed to make pkgbuils with package.install which compiles itself when the *.install is ran (like pacman -A moopackage.pkg.tar.gz); this would be awesome for kernel modules!
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 02:58:14 nut543 i dread the time of linux before google ...
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 02:58:25 nut543 must have been nitemare
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 02:59:31 iamsthitha nut543, some packages compile themselves..
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:06:12 nut543 iamsthitha, you mean when u do p -A moo? which ones?
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:06:46 iamsthitha nut543, the who what?
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:07:35 nut543 iamsthitha, which packages..
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:07:50 iamsthitha nut543, everything in AUR
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:08:02 nut543 no you misunderstood
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:08:03 iamsthitha nut543, I'm guessing the nvidia drivers..
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:08:40 nut543 iamsthitha, so not when u do makepkg?
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:08:47 iamsthitha nut543, oh
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:09:16 iamsthitha nut543, well I do know you can execute custom commands when you install a package
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:09:29 nut543 iamsthitha, yeah but prolly illegal?
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:09:32 iamsthitha nut543, so you could put the compile commands in there.. but its lame
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:10:22 nut543 iamsthitha, no kernel modules take 3hrs to compile...
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:10:55 nut543 besides if they are the few very big ones, one could have already built ones for those...
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:10:56 iamsthitha nut543, then nothing's stopping you from doing it..
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:11:13 nut543 no! weee! linux! opensource!
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:11:17 iamsthitha nut543, yea.. why not just provide prebuilt kernel modules?
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:11:20 nut543 change the tidal wave!
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:11:40 nut543 iamsthitha, they don't support all kernels... not custom made ones. blabla
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:11:49 nut543 less work for the packager..
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:12:09 nut543 more ways and faster distribution
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:12:25 nut543 more kernel modules in repo..
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:12:45 nut543 easier installation..i trust you see the advantage here
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:14:04 nut543 iamsthitha, but AUR is not in abs?
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:14:32 nut543 and aur takes time...
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:15:26 nut543 iamsthitha,
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:15:56 nut543 iamsthitha, aur time would be sped up if we were allowed to make kernel module packages like that
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:16:13 nut543 or maybe we are allowed idont know lol
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:18:31 iamsthitha nut543, why dontya try it and find out
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:18:40 nut543 iamlazy
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:18:51 nut543 haha
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:21:17 nut543 What awesomness takes three hours to compile and is a module?
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:21:33 iamsthitha nut543, your nuts?
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:21:58 maito nut543: 3 hours?
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:22:08 maito nut543: i compile a kernel with defaults in 10min
.xchat2/xchatlogs/FreeNode-#archlinux.log:jan 22 03:22:57 nut543 then you have a ũbersõperdûbermacHINABEAST

Romashka · 2006-01-22 13:28:33

I have much experience with MySQL, SQLite, DBM etc. and must say that the latest SQLite 3.3 is really the best choice for Pacman 3. As for PyTables - they are good but Pacman is written in C, not in Python, and anyway package database is not so large so the speed of SQLite is more than enought. And complete in-memory database is a bit overkill.
The pros of SQLite are:
* written in C
* embeddable
* implemnts most of SQL92 including ACID transactions
* thread-safe (well, almost)
* small footprint
* public domain

test1000 · 2006-01-22 16:34:07

but PyTables is based? on HDF5 which, i assume, is built in C.. so maybe it would be better for pacman to use HDF5?

Romashka · 2006-01-23 10:29:05

No, I don't thinks so. The speed of SQLite will be enought for Pacman. SQLite is very fast, but also it is full-featured embeddable SQL engine with small footprint. This is the main reason to choose SQLite. It will be not only easier to integrate it with Pacman than any other soultions, but it also gives the power of SQL to Pacman which will make all operations with database much easier.
It is simply not worth implementing HDF5 backend as Pacman's database.

test1000 · 2006-01-24 19:52:20

i wonder how ppl with P2's will see your SQLite is "enough" argument.. will it be fast also for them? will it be instant for me then, since i have a 2.4 ghz? Your other argument is that it will be easier to integrate, which i don't know if it's true.. (It can't be THAT much harder). Even so, it's not really an argument per se, since only the very programmers coding pacman3 will care about this; 99% which constitute the rest of the arch population which DOESN'T code pacman 3 will not see the advantage here.

From _your_ standpoint i can see why you don't see implementing HDF5 as pacman db will be worth it.. after all you don't see the work to gain factor as a _programmer_; but don't think the rest of the ppl actually going to use pacman will see the benfit of sqlite when there is a faster solution out there.

in closing: I can't _demand_ anything, but i'm still going to express my views

Romashka · 2006-01-25 07:46:44

I have Celeron 600 MHz, 128 MB of RAM and not fast HDD (old Samsung 40 GB). I tested SQLite with databases up to 120 MB in size and I can say that SQLite is very fast.
And anyway - older processors are not i686.

Why do you want the fastest database in the world for Pacman? It is like shooting birds with cannon. There are also another very fast solutions, maybe even faster than HDF5, for example CDB. But the most reliable solution will be SQLite.
And implementing Pacman's backend database as SQLite can be done with much less effort and will have much more benefits. And those benefits will be for all users, not only for Pacman programmers.
And instead of writing some basic code that will allow Pacman to use HDF5 programmers can concentrate on other tasks because SQLite already has all that is needed and even more! That will benefit all users.

I say this not only as a programmer but also as Arch user.

iphitus · 2006-01-25 08:18:39

as for 1) that just breaks the package. As theres no simple way to record what files are actually installed in the system.

as for 2), sqlite. Actually look at those results. How many of them are reliable sources? How many of them are even practical? I would leave arch if it were to use mysql for the package database. Pytables? Pytables.

SQLite is a known good, maintained, small, reliable, and for the purposes of a package manager, well and truly fast enough.

test1000 · 2006-01-25 22:34:42

ok Romashka, your the programmer.. your the one with the tests guess i'll take your word for it.

test1000 · 2006-01-25 22:50:42

and for the kernel-modules; maybe we could add some more pacman compatibility for them aswell; like installwatch monitoring what gets installed in the install.programname file if it's a kernel module and making a package out of it.
Or preferably something less hackish(aslthough it would probably work?).. wouldn't it be nice if we had a tool to install kernel modules, where the "packages" shouldn't need to be compiled beforehand but introduced compatibility with the running kernel on the users system by seeing what kernel ver. the user was running an then using the appropriate patch? if it hadn't got a patch already it could refrain from quitting if the build failed, but simply let the user check the error msg'es and edit the file of his choosing: cos most times, it's just a matter of a simple edit to get a kernel module to build(well in my opinion atleast) (then ideally the user could upload the patch to the system if he got it working so that the next user would have a patch ready-to-go! maybe this could go trough a TU or someone for security..)

i don't know, maybe i'm sleepdeprived here or does this sound like a good idea?

phrakture · 2006-01-26 00:29:36

Romashka wrote:

Why do you want the fastest database in the world for Pacman? It is like shooting birds with cannon.

Freaking signed!

Arch Linux

#1 2006-01-22 02:05:24

Pacman issues...

#2 2006-01-22 13:28:33

Re: Pacman issues...

#3 2006-01-22 16:34:07

Re: Pacman issues...

#4 2006-01-23 10:29:05

Re: Pacman issues...

#5 2006-01-24 19:52:20

Re: Pacman issues...

#6 2006-01-25 07:46:44

Re: Pacman issues...

#7 2006-01-25 08:18:39

Re: Pacman issues...

#8 2006-01-25 22:34:42

Re: Pacman issues...

#9 2006-01-25 22:50:42

Re: Pacman issues...

#10 2006-01-26 00:29:36

Re: Pacman issues...

Board footer