How is this going to affect the fink development?
I think Benjamin already answered this one: We'll have a few more people porting things to OS X, and otherwise Fink will just go about development normally. Fink competes with Gentoo in the same way that Oxfam 'competes' with UNICEF.
Is there anybody in the fink team who knows more about gentoo?
I recently installed Gentoo Linux. I've been hacking on some Portage tools a bit too. My knowledge of both Fink and Portage is necessarily incomplete, and I apologize in advance for the blatant errors I'll commit--but there are a few features of Portage that are interesting and worthy of comment. I'm not saying they should be implemented or anything, I just want Fink devs to know of alternative approaches so that 1) we can consider them if and when we need them and 2) we can point people somewhere when they ask "why don't you add this?".
1. USE variables: This is basically the 'variant' support that has been talked about on the list for a while. Portage uses global variant options--a reasonable way to not ask the user each time, but it does require setup. The existence of many variants makes it difficult (impossible?) for all combinations to be tested. It also makes dependency management tough, and portage punts on some dependency issues (no equivalent to 'apt-get remove', for example). Personally, I'd expect variant support to be quite difficult to add to Fink, and would not want to try before we have versioned provides in dpkg--it would also involve policy issues re: testing.
2. Sourced package files: Portage's .ebuild files (the equivalent to Fink's .info) are just 'special' sh scripts, which are sourced to set env vars--they can do this dynamically with if or case constructs. Fink .info files are just literal fields, with only a few percent-expansions. Sourced package files make possible many of the conditional fields which are needed for variants. Otherwise, they don't seem too useful and just add complication. A Fink-with-variants would need some kind of conditional structure, but right now I don't see the use.
3. Eclasses: A .eclass file is more or less a partial ebuild file. Ebuilds or other Eclasses can then inherit from the eclass (like inheritance in OOP), adding and overriding fields as needed. This is usually used like Fink's 'Type' field, but more easily extensible. It might be useful to deal with perl, python and emacs modules, kde, and other groups of similar packages with a system such as this, and it looks possible for someone to add this to Fink if he/she wants it.
4. 'World' file: When a user 'emerges' (builds and installs) a package, portage adds this package's name to the 'world' file. Only the actual packages that are requested get put there, not the dependencies. Later, when dependencies change or packages are removed, portage can use 'world' to figure out what packages were installed as dependencies but are no longer needed, and 'clean' them out. Fink currently doesn't track this information, so sometimes one accumulates unwanted packages just by doing selfupdate-cvs and update-all. This isn't necessarily the greatest feature, there seem to be a lot of Portage users who are dissatisfied with the way Portage does it. Might be a bit tough to add if someone wanted it (I don't think I do), since you'd have to modify both Fink and apt to add names of requested packages and remove those of removed packages.
There are other differences of course, but these are the major ones that stick in my mind right now.
Toodles, Dave
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
