At 17:13 Uhr -0500 25.02.2003, Kyle Moffett wrote:That IS odd! I just use Mail.app, so I have no clue. OH!!! Wait! Mail.appOn Tuesday, Feb 25, 2003, at 11:15 US/Eastern, Max Horn wrote:Hm I wonder why your email client misreads my time zone like that =)
converted the time 'Tue, 25 Feb 2003 17:15:22 +0100' into my time zone,
so that I could compare to other mails I got from the list. ;-)
I see, Benjamin pointed this out to me. Where do you find pkg-order? Thanks.I never intended to use pkg-order as an external tool, that wouldn't be possible anyway. Rather I meant to use its code (which is under the GPL). THough ideally with as little changes as possible (mainly adding things, not changing them) to make migrating to new upstream versions possible.Or possibly take code from pkg-order, add additional features, etc, and put it all into a perlmod.The proper way --------------
Proper would be to (as I mentioned in the past) have a full fledged package orderer that is aware of the fact that build dependencies can be removed after they have been used. My hope is that it's possible to add support for this to pkg-order, maybe one could even get support from the pkg-order author(s) for this project. However, I consider it a hard piece of work to be done properly.
I just thought, "Hmm, with a bunch of work, we could do it using a neat colored directional graph and possibly make it easier to add features to in theThis would be the hardest, but I think that with a little thought we can come up with some kind of colored graph algorithm that makes the process a little easier.Uh, no idea how you envision that, but feel free to actually explain it. Don't stop at the "oh we could maybe do it that and this way, it should be doabl", think it fully through, then present it. Cause there are dozens of pitfalls which are easy to overlook when designing this on paper... :-/
future." You're right, though, about the difficulty of the project. I have tried several simple directional graph schemes on paper, and most of them failed miserably. The rest were just incredibly obtuse and inefficient. I am not very good at graph theory, though, so I am sure that I missed something(s).
I think that the most difficult part of this system is not the build-{depends,conflicts}, but the issue
of versions, provides, and replaces. Here is another idea that resolves multiple simultaneous
runs and multithreading issues:
For each package named on the command line
Create a stack containing only the named package and the action (Build,Install,Remove).
While there are packages on the stack:
Lock the file /sw/var/fink.lock for writing
For each unsatisfied dependency
If a dependency is missing
Figure out how to fix it # <-- Note here
Try to add it to the lock file
Push it onto the stack
If nothing has been pushed onto the stack
For each dependency in the lock file
If this level in the stack is the only one that has it locked
Remove it from the lock file
Unlock the file /sw/var/fink.lock
Otherwise go to the top level of the stack and continue
Please give your thoughts, ideas, input, etc. This is kind of a preliminary idea,
so it is probably as full of holes as swiss cheese. It does need a way of taking
various Provides, Replaces, etc, and determining what packages conflict with
others, and what packages depend on others. This could likely be solved with
a directional colored graph, where for each 'Depends:' item, there is a list of
other packages that satisfy the dependency, etc, which is fairly simple to
generate Then finding each dependency only requires a quick enumeration
of an array.
One of the problems with this is that it does not allow the system to try other
dependencies while waiting for a lock on a package.
For prompting the user, this should be run once at the start without actually
performing the actions and just assuming that they succeed. During that
cycle, when multiple possibilities are found, the user can be prompted right
away. Using the graph described above, only the satisfiable dependencies
would be listed. All the results would be cached for use during the actual
build. As the build is progressing, the choices are verified again. If any
choice requires modification of a package not identified to the user initially,
AKA: Some other fink process installed or removed something, then prompt
about it.
Please give me any feedback at all on this stuff! Thanks!
That's ok, Ben explained it well.That was always my intention, though I didn't cleary mention it hear as such, sorry.Also, when in doubt about multiple possible ways to fulfill a dependency, it should be possible to either let fink make a good (automatic) guess at it, *or* let fink ask the user what he prefers. Not sure how hard it would be to implement that atop pkg-order.Rather than using an external perl program, why don't we just adjust the code into a module and use the functions straight from fink.
Cheers, Kyle Moffett
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCM/CS/IT/U d- s++:- a16 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L+++(++) E W++(+) N+++(++) o? K? w---(-) O? M++ V? PS+() PE+(-) Y+ PGP? t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h! !r-- !y? ------END GEEK CODE BLOCK------
------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
