At 12:50 Uhr +0100 31.01.2003, David wrote:
On Freitag, Jˆ§nner 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 not.
Basic needs and issues
======================
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?
For 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
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 :-)
Cheers,
Max
-------------------------------------------------------
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
