On Thu, Apr 06, 2006 at 05:47:25AM -0400, Dave Vasilevsky wrote: > > On Apr 6, 2006, at 2:54 AM, Daniel Macks wrote: > >>Yeah, but neither works for other tree than the one I am using right > >>now, do they? > > > >By "other tree", you mean in the Distribution sense (can't check 10.3 > >from a 10.4-transitional machine; can't check intel from a powerpc > >machine) right? The --trees flag *overrides* Trees in fink.conf. > > No, it doesn't. It *selects a subset* of the Trees in fink.conf. You > can't use it to include a tree that's not in your fink.conf. (It's a > design choice so that --exclude-trees makes sense.)
Interesting...I guess I've never tried it except on machines with unstable (and other stuff) all enabled in fink.conf. Not sure I agree with the design decision, but pretty sure I don't care enough to push to change it:) > So anyways, what Max is really asking is about Distributions. And > unfortunately, there's no good way to check if a package's deps would > be satisfied in another Distribution. This is because the "virtual > packages"--representing the kernel, gcc, X11, perl, etc--are all > different, and fink has no way to know what versions of those you > would have on another Distribution. > > Fink can already read the .info files from another distro, if you > play some tricks like changing when %p/fink/dists points. So if we > want to test what would happen on another distro, we could put > together some code to make Fink::VirtPackage pretend that a certain > set of virtual packages are present. (We could also do this to > Fink::Status, to pretend that a different set of packages are > installed.) Then just generate for each Distribution what we'd like > these sets of packages to be. > > Max, would you like to help implement this? Dan, any thoughts? Do we assume that if a user is forging $distribution, it should only be for use within fink itself (for dep-checking and listing), not actually to be able to install these packages? VirtPackages already list of standard packages that it expects to have on various normal systems. If the underlying files a package represents are not present, it considers the the package "not installed", not "no such package". If we just want to populate the package database to look like a forged $distribution in terms of package existence, just have VirtPackages consider *all* its packages as "not installed" regardless of what's on the local filesystem. Status is just a subset of .info data when the package that is installed is at the current version (with the addition of a bit saying that the package is actually installed, obviously). If one is not planning on actually installing anything, does one really care what packages "are" installed on this alternate $distribtion? Or would we be okay just disregarding Status entirely in this case? My thinking here is based on what I did for forging $architecture... if the arch the user has forced does not match the native one for the local machine, VirtPackage sets all its packages STATUS_ABSENT and Status considers dpkg to have no packages installed. One can run the dep engine, see what fields look like with %-expansion and conditionals processed as for a foreign $arch, but one cannot go so far as to compile or install packages if $arch is forged. It's a "what-if" game for fink, it doesn't actually enable fink to do a live cross-$arch system. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
