IRC Logs for #crux-devel Tuesday, 2011-02-15

*** mike_k has joined #crux-devel01:31
*** acrux has joined #crux-devel04:20
frinnstand as per always said, its just "crux", not "crux linux" :)04:54
prologic*meh* you're right05:29
prologicI often like to say CRUX/Linux though just to be clear :)05:29
*** mike_k has quit IRC05:51
*** mike_k has joined #crux-devel05:52
*** prologic has quit IRC07:29
*** prologic has joined #crux-devel07:57
*** prologic has joined #crux-devel07:57
jaegernot CRUX GNU/Linux Basics?08:44
enteGNU/CRUX GNU/Linux08:45
prologicwe're not GNU though ?08:46
prologic:)08:46
entenever08:48
enteyou can never be GNU enough, not even if you use GNU/coreutils and GNU/grep and GNU/gnus on GNU/emacs :P08:48
* jaeger feels GNU enough08:54
entedo you feel the GNU? :P08:54
entethe GNU operating system is kernel /hurd init=/emacs08:55
*** prologic_ has joined #crux-devel09:37
*** prologic has quit IRC09:37
*** prologic_ has quit IRC10:42
*** prologic_ has joined #crux-devel10:54
*** jue has quit IRC11:56
*** ente has quit IRC11:56
*** acrux has quit IRC11:56
*** pitillo has quit IRC11:56
*** jaeger has quit IRC11:56
*** acrux has joined #crux-devel12:00
*** ente has joined #crux-devel12:05
*** pitillo has joined #crux-devel12:06
*** jue has joined #crux-devel12:06
*** jaeger has joined #crux-devel12:10
*** jaeger has joined #crux-devel12:23
*** jaeger has quit IRC12:54
*** jaeger has joined #crux-devel12:55
*** prologic_ is now known as prologic15:37
prologicBtw...15:39
prologicWhat does everyone think of the distro agnostic installation framework being presented ?15:40
prologicI looked over his slides and well umm I'm not particularly very interested in developing a framework in Bash15:40
prologicuggh15:40
jaegerI have no particular opinion on it except to say, "go for it if you want to, it's interesting"15:40
jaegerNot super interesting to ME but interesting to him/her I guess15:40
prologicyeah well I agree with your stance15:41
prologicI do believe a better more appropriate language could be used though15:41
prologiceg: Python15:41
jaegerI saw you mention that15:41
prologicif we were to adopt such a thing, so our core depends on python now ? so what15:41
prologicIHMO complex Bash applications (let alone frameworks) are maintainer nightmares15:42
prologicTo that end ... I actually started writing a direct port of pkgutils and prt-get in python - but have abandoned the work for some time now15:43
jueTBH, I don't see a reason for a more complicated installer15:43
prologicno, neither do i15:43
jueat least currently15:43
prologicthat's what my point was too15:43
jaegerI don't see a need but I encourage people to do projects to learn :)15:43
prologicI believe I tried to say that normally it takes all but 5mins to install CRUX's core (minus kernel configure/compile time)15:44
prologicand it couldn't be easier15:44
prologicin fact - we could even get rid of the setup script altogether15:44
prologicone could just as easily go cd /path/to/core/pacakges15:44
prologicpkgadd *15:44
juewell, not at all15:45
prologicthe setup script doesn't really provide you with anything that pkgad can't do :)15:45
jueI think the dep-check is nice and the setup-helper is a must have15:45
prologic(other than package selection)15:45
prologicbut normally you just want to add all of core15:45
prologicsetup-chroot - yes15:45
prologicI will install a system this way just to prove my point :)15:46
prologichaha15:46
prologicall the usual steps15:46
jueno, not setup-chroot, I mean setup-helper15:46
prologiccd /crux/packages/core/15:46
prologicpkgadd -R /mnt *15:46
prologic:)15:46
prologicwhen do you run setup-helper ?15:46
prologicor is that used by setup ?15:46
jueit's run by setup15:46
prologicahh15:46
prologicI think you're missing my point :)15:46
jueto do package renames, package injections and packahe removes15:47
prologicI'm talking about a fresh install15:47
prologicnot an upgrade nor custom package selection15:47
prologicjust pkgadd all of core15:47
jaegerIt is already easy but it doesn't need to be obscure/obtuse15:47
prologicagreed :)15:47
jueok, but we have to deal with updates as well15:47
jueat least a bit ;)15:47
prologicI honestly don't think an installation framework will give us anything though15:47
prologicmy 2c15:48
prologicyou know what though ...15:48
prologictalking about updates15:48
jaegerI don't see a need for it for crux but I say go ahead and design one if a) you want to, and/or b) it'll get used somewhere15:48
prologicwho developers prt-get these days ?15:48
prologicwhat we really need (which I dno't think we have) is for prt-get to grow some update smarts15:49
prologicfor example15:49
prologicyou update port xyz15:49
prologicwait lemme start again15:49
prologicyou have port xyz that depends on abc15:49
jaegerAre you referring to added deps?15:49
prologicabc gets updated15:49
prologicprt-get updates xyz too15:49
jaegeror library linkage?15:49
prologic*nods*15:49
prologicyeah15:50
jaegeror both15:50
prologicfixing the annoying library dependency issues15:50
prologicwhen something gets updated15:50
prologicthen breaks other things15:50
prologicif prt-get update respected dependencies and updated dependents and dependencies15:50
prologicnot sure if both are necessary15:50
jaegerHow does it know when one breaks? run revdep on the quickdep list every time you update?15:50
jaegerIt would introduce a significant slowdown15:50
jaegerI'm not against somehow solving that, for reference, it's just a bit of an odd issue15:51
prologicI think (optionally) we could make options in /etc/prt-get.conf15:51
prologicthat prt-get update would make certain assumptions15:51
prologicno need to do checking15:51
prologicjust rebuild the ports15:51
prologicyeah I agree it is an odd issue15:51
jaegerIf it didn't run revdep but assumed a port needed rebuilding, that could add a lot of unnecessary work, too. for example, xulrunner, which takes a long time to build15:51
prologicI'm not entirely sure how to solve it myself either yet15:51
jaegerso it would need to be pretty smart about figuring out what needs rebuilding15:52
prologichmm15:52
jaegerAs well as the option to opt out or opt in15:52
prologicagreed15:52
prologicIs there a more efficient way of determining if a dependency or any dependents needs updating ?15:52
prologicother than revdep (which is slow)15:52
jaegerNot one that I know of off the top of my head15:52
prologiccould we simply (for example) search for broken libraries (missing) ?15:53
prologicsurely Gentoo have solved this same problem no ?15:53
juethat's what revdep is doing, searching for broken lib-links15:53
jaegerrevdep-rebuild in gentoo essentially works the same way as revdep in crux15:54
jaegerUnless there's some kind of QA notice in the ebuild or something I don't know about15:54
jaegerSomething that pkgutils limited metadata wouldn't make easy15:54
prologicwhy does revdep take so long anyway ?15:56
jaegertake a look at it :)15:56
prologicis it because it's searching for broken libraries for all installed ports ?15:56
prologicI will!15:56
jaegerfor all ports you specify (or all if none are specified)15:56
prologichmm15:57
prologicI don't think it takes any arguments15:57
juesure, see revdep(1)15:57
prologicyeah yeah I saw it :)15:57
prologicreading the source15:57
prologicit does take any number of arguments15:57
prologicports to check15:57
jaegerIt's very simple but it invokes other commands. pkginfo, awk, ldd, file, etc.15:58
jaegerso it's not extrememly efficient15:58
prologichmm15:58
jaegerI'm not sure how it could be improved, though, without rewriting it in C or something15:58
prologicthat's why it's so slow15:59
prologicforking15:59
prologicand no means of parallelising it15:59
prologicin core we basically have the choice of16:01
prologicbash, perl or C/C++16:01
prologicshame I no good at any of thsoe languages :)16:01
jaegerI know basic C/C++ but that's all16:02
prologicI know basic C16:02
prologicenough to write simple stuff16:02
prologicthe only other way to do this of course16:03
prologicis to have triggers pkgadd16:04
prologicthat build a database that can be searched quicker16:04
prologic(avoiding forking and invoking external tools)16:04
jueI'd say that calling ldd for every shared object is much more expensive16:07
juethan searching the package db for the files that belongs to a package16:09
prologicit is16:09
prologicbut what if we maintain a new database for this ?16:09
prologicor add to pkgutils's database16:09
prologicso what way we don't have to call ldd each time16:09
jueyou mean a db with all the library names a binary is linked to16:13
prologicyeah something like that16:13
jueso you can scan the db an look for missing files?16:13
prologicprecisely16:13
jues/an/and/16:13
prologicit would be a lot faster searching a flat file than calling ldd many times16:14
jueyeah, certainly16:15
jueanyway, it's time to sleep for me16:16
juenight all16:16
jaegertake care16:16
prologicI think we should do this16:18
*** mavrick61 has quit IRC17:06
*** mavrick61 has joined #crux-devel17:08
*** mike_k has quit IRC17:20
*** mavrick61 has quit IRC21:37
*** mavrick61 has joined #crux-devel21:38
*** nthwyatt has quit IRC22:50

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!