David R. Morrison wrote:
Dear Fink developers,
Hi Dave, nobody else seems to have bitten, so I'll bite.
The question arises, then: should we have a separate 10.4 tree, and if so, when should we start to work on it?
I believe that we will indeed want to create a separate 10.4 tree, but that there will be virtually no changes needed in packages between the 10.3 and 10.4 trees. However, we will probably want to make changes in the way fink builds things, and -- unless we want to manually go through and change revision numbers in packages -- this is the best way to do that. We preserve our philosophy of "any machine you build it on produces the same result for the same package", as long as it is recognized that "same package" refers not only to the version number, but also to the tree.
This seems a little extreme to me, I don't think apple is going to do anything much to require us to have a new tree for 10.4, our reasons in the past included g++ binary incompat (no longer an issue), new perl version (we should be able to deal with that in the same tree, major changes to libSystem (does not look like these will affect fink at this time). I'd like to suggest a kind of halfway position here. Since Dan added the code for variants, it had me wondering if it could be adapted to take care of the differences between trees. We could have a "Distributions: 10.3 10.4" line in each .info file which would tell when the package would appear in listings etc. and would allow for variations in the package between trees. This would all have to be implemented, of course, and the new distribtion for each OS release thing is already a known quantity. However, if we are to support 10.3 for a year after 10.4 is released it would mak elife much easier if there were only one or two copies of each .info file to mess with each time one needed to update them.
If I am right, and virtually no changes will be needed in packages, then we should wait until the last possible minute to create the 10.4 tree. At that time, we can copy over the 10.3 tree to 10.4 (possibly with some automatically-made changes in packages). The later we wait, the easier it will be to keep the trees in sync and up to date.
What sort of changes might we make in fink for 10.4? (1) There is a good
chance that we'll want to change our prebinding strategy, (2) we'll
probably want to build with MACOSX_DEPLOYMENT_TARGET set to 10.4, and (3) we can implement which didn't get done in 10.3: a new policy that all
packages must explicitly state their dependencies on essential packages.
(More about this below.)
I think we can make most of these changes "in place" without the need to have different trees. WE can talk about lots of this stuff, anything that appears on <http://www.opensource.apple.com/darwinsource/WWDC2004/> can be talked about. So we can mention that dyld is quite different (even in 10.3.4) and that it may not really be much of a gain to do prebinding anymore. We can mention that the perl which shipped with the wwdc seed is 1.8.4, we can say that the linker has a new flag to dead strip code etc. etc. We can do all this and not break our NDA.
I hope we can find a way to set up a private mailing list for use by those of us who have ADC Software Seed Keys, to discuss further issues about 10.4 as they arise.
This is still a good idea, I can set up a mail alias if need be (you'd get copies of your own posts that way, but there would be no archive for the public and it could be kept private among seed key holders, assuming we could come up with a way of verifying who is a seed key holder).
P.S. Why explicitly state dependencies on essential packages? This is the
only way to have an upgrade strategy for our essential packages. For
example, gettext has been upgraded with a library compatibility change, so
eventually we want to replace gettext with gettext2. During the
transition, though, gettext-shlibs dependencies will need to be explicitly
stated.
How to do this? We can automatically add dependencies on all essential packages during the copying from the 10.3 to 10.4 trees. Then, as time goes on, developers will be free to remove those dependencies when they revise their packages, if the dependencies are not actually needed.
I think this can also be done "in place".
Peter -- Peter O'Gorman - http://www.pogma.com
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
