From: Max H. <ma...@qu...> - 2003-01-31 12:11:02
|
At 12:50 Uhr +0100 31.01.2003, David wrote: >On Freitag, J=88=A7nner 31, 2003, at 01:01 Uhr, Max Horn wrote: [...] >I think that it would be an excellent idea to use something like a >Wiki. If you want I can install such a system on one of the boxen I >have authority over. <shrug> Never got the hang of Wiki's, but if you want to isntall one, why no= t. >> >>Basic needs and issues >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>First off: the engine needs to deal with 4 basic types of dependency: >>* build conflicts >I never quite understood what a build conflict is. Maybe you could >point me toward and example? =46or example sdl-ttf which can be installed parallel to freetype 1.x, but if you build it while freetype 1.x is installed, it'll fail. Luckily in many cases one can use a "BuildDepends" instead of a "BuildConflict". But adding this ensures our system is fully orthogonal and really doesn't cost us anything. >>* build dependencies >>* install conflicts >>* install dependencies >> >>Note that the current "Depends" field in fink in fact represent >>both a build time *and* a install time dependency; in a future fink >>package manager release, we will hence add new fields >>InstallDepends and InstallConflicts (names subject to change); this >>will increase the flexibility w/o adding any complexity. >> >So an install dependency is something like a run dependency in >FreeBSD? Those packages would list other packages which need to be >present prior to installing the package because: > > a) it needs them to install properly (because it uses >tetex to generate doc during install) > b) it needs them to run properly afterwards You a) is our build dependency, and b) is an install (or "runtime" as I used to call it) dependency. It's debatable which term ("install" or "runtime") is better suited, IMHO none is quite correct. [...] >I would like to suggest the following addition then. I have been >working for many years in areas where parallel processing was able >to mess with data structures. Would it be possible to implement a >"locking" mechanism within fink? Take your example. If a package >starts at time X and needs package DFG to build those packages will >be locked exclusively to that build process. If you run fink at time >Y while teh first build is still in progress, the packages DFG will >still be locked and thus they cannot be altered or removed. Of >course I am referring to special locks. I don't think that will work, unless you modify dpkg and apt-get to use them, too. The only way I see (and which I briefly mentioned in my original post) is to make fink use the same locking mechanism as those two, but it's not fine grained at all, and at least to me would be a serious limitation. It would prevent me from doing e.g. a "fink install figlet" while my "fink install bundle-kde" is running. Anyway, the "chroot jail" approach that I'll explain in the next full email covers this rather nicely without the need of any locks. But while you already mention parallelism, I also made my thoughts about this. The "objective optimizer" I talked about could also be made clever enough to distribute objectivies onto multiple processes (or even machines in the distant future :-). Like it could detect that we are on a two processor machine, and in that case spaw multiple subproceses and then try to keep them saturated with building packages. Of course that still has the same problems it used to have (like, we can't just print the output to the terminal anymore, or we'd get a big mess), but at least with the new approach it would be possible to do this. Which is important, since the new system would also easily allow a "fink build-all" (Justin, your dream come true, eh? :-) [...] >>This can lead to three cases: >> 1) we can find one version of "foo" that leads to no issues >> 2) we can find more than possibility >> >What happens when we find more than one choice and one of the >choices is not available? For example the download fails. Now one >choice only requires XXX as dependency. The other choice requires >XXXYY and that might force a recalculation and a new queue which >needs to be calculated. > >Does the system do something like: > >You could either install X or Y you chose Y but it is not available, >shall I install X and recalculate the dependencies? This might be doable one day, but I would not want to do this at the beginning. We can keep it in mind, but right now I think it would complicate the system. It's already difficult enough to get this all done, so let's postpone that for a later version. >> <snip> >Ignore my rambling if I am talking bullshit, I am just getting the >hang of this and how it is being handled. I simply feel, that it is >important to let go of all the ideas which might swirl in my head, >no matter if they make sense at the first attempt. Yup yup, you are most welcome to do so! I think your ideas all made sense. Now for anybody who got this far reading, my second email will probably be coming this evening/night. And I slowly start to think maybe I can even start work on a prototype, though I must say I am not sure if I like to do it in Perl. Nothing against Perl, I am just not used to handling complicated structures in Perl, so I first gotta learn that (thank god I have Randall's book and the Perl book, too... at home, 400 km away :-). The part of Fink which deals with "structs" and linked list etc. is after all the single most complicated part of =46ink. I am just more home in C/C++/Java/... so I might scribble down (non working) designs in one of these languages. Or maybe I just use pseudo code :-) Cheers, Max |