On Freitag, Jänner 31, 2003, at 01:01 Uhr, Max Horn wrote:
Hi folks,
Hello Max.
I do not know nor do I like C++, but since I am rather grown up with my C, I am sure I can push the OO syntax into the back of my brain quick enough. However if we write something new, can't I be the wizard if C ? *grins*
For some time, I hoped we might be able to just reuse the apt engine (and the hope is still not completely gone), but as far as I can tell it can't cope with build time only dependencies (but there is the possibility to work around that, see below). If somebody is interested to look into this (that means you have to know C++, and ideally also the apt sources, or are willing to work into it), feel free to contact me.
So, for now, instead of charging ahead and trying to write a new dependency engine from scratch or trying to retrofit an existing one, I went to try to write down what our needs are. Then based on this, I started to develop ideas on how to realize these needs in actual code. I try to present all my ideas and findings in this email. That includes a list of problematic cases the engine needs to handle, as well as fundamental problems, and problems that are also affecting our current system. It'll be a long email, and maybe I should put it on a web page later, too.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.
I never quite understood what a build conflict is. Maybe you could point me toward and example?Basic needs and issues ====================== First off: the engine needs to deal with 4 basic types of dependency: * build conflicts
* build dependenciesSo 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:
* 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.
a) it needs them to install properly (because it uses tetex to generate doc during install)
b) it needs them to run properly afterwards
<snip>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.
Another trouble area are build time dependencies, and build time in general. Right now, fink installs build time dependencies if needed, but doesn't remove them later (which might or might not be the right approach, you can argue either way). We don't handle build conflicts at all. Also, there issues when users run multiple fink's at once (I do that frequently - no need to interrupt KDE building if I just want to quickly install figlet). Right now, this can easily lead to screw up. Just imagine openssh is building and the user removes the openssl package. Ouch, either the build fails, or gets messed because the openssh build now starts using Apple's openssl - just imagine if the version of openssl differ, then half of openssh is linked against openssl 0.9.7, the other against 0.9.6 - ouch).
dpkg doesn't (and can't) handle build time dependencies at all. Fink should do that, but right now it does a very poor job at it.
apt only handles them in a very limited way (for the apt-get source command), not sufficient for our needs.
Let us assume this.
a) a remove lock (packages which are locked that way cannot be removed until the lock has been released) Now that means we either queue the release passively or the package is being removed actively by the locking build
b) .... insert your idea here ..
Ideas & Solutions
=================
I developed various ideas on how to tackle the problems above and other problems I encountered while researching this. Note that I am still not finished yet with all this (one of the reason for me to finally write this down was to get my thoughts ordered, it's easy to get lost :-).
And basically, this assumes we use write own engine...
rock on.. yes..
<snip>
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.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
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?
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.<snip>
-d
- ❜ Fantasie ist wichtiger als Wissen.❛ - Albert Einstein
-------------------------------------------------------
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
