<snip>
<shrug> Never got the hang of Wiki's, but if you want to isntall one,
why not.
Well I do not use them either, but I thought they would be suited. But
then again.. who cares <g>
<snip>
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.
Thank you, now I get it.
<snip>
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.
Yes, I tend to forget, that we have to work with apt/dpkg as well.
Anyway, the "chroot jail" approach that I'll explain in the next full
email covers this rather nicely without the need of any locks.
chrooting is indeed a choice which seems feasible, yet as you already
mentioned this might increase HD use in an exponential way, especially
when we start allowing parallel builds in a way that it is safe to use
them.
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? :-)
I agree. I do see some problems though because locking is a real issue
then. Unless the system is able to distribute multiple "objects" across
multiple "jails" while still keeping the build coherent.
<snip>
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.
as I said, it was merely a question, keeping this in mind then.
<snip>
>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"
But you have the author much closer... right here.. on the list (just
kidding, sorry Mr. Schwartz)
and linked list etc. is after all the single most complicated part of
Fink. 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 :-)
oh yes please.. C baby ;) Maybe I can start optimising some of the
linking and calculating and node moving in asm *drool*
-d :)
- Face me and you shall surely perish.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
