Am 09.11.2009 um 19:10 schrieb David R. Morrison: > > On Nov 9, 2009, at 9:54 AM, Peter O'Gorman wrote: > >> >> This is the problem fink now has with its Update* fields. Updating >> the files that will be copied may fix some things, but may break >> others. >> > > Maybe we should introduce new fields for the new updates? With names > like ModernizeConfigGuess, ModernizeLibtool ? > > The idea would be that if you want the 2001 version, you use Update* > and if you want the 2009 version, you use Modernize*.
And in 2011 we introduce UseReallyModernConfigGuess, UseReallyModernLibtool ? :) Nah... this seems like the wrong way to go about this. I see two major alternatives to go with. Note that the following is just meant as a *sketch*; I can think of tons of ways to vary each approach myself, and I am sure each of you can think of additional ones. (1) Get rid of these UpdateFOO fields completely. Instead, require package which have to update config.guess etc. to insert these updates some other way: By rerunning auto-tools; by adding the correct config.guess etc. version as a SourceN (care required to avoid name clashes, though), as part of the patch (would lead to pretty big patches, though) etc. Pro: No funky special rare field which requires extra code to handle, and in general makes things more complex. The fink package manager code gets simpler. Con: Somewhat less convenient to use. No problem IMO for the current uses of the UpdateFOO field, but this is a drawback if we want to use this to tackle the "64bit issues". Slight variation: Make a package which contains current versions of config.guess, config.sub, etc., and let things that need those depend on that package. If at some point we need even newer versions, we make a new package. We also could make a package which contains the old fink/update/ versions of the files, and migrate all packages using UpdateFOO to use these, thus allowing us to completely get rid of UpdateFOO. (2) Keep the UpdateFOO fields, but modernize them. That is, extend the values allowed from true/false to a fixed list multiple values indicating the file "version", like this: UpdateConfigGuess: 2009-09-18 For backward compatibility, we'd still allow UpdateConfigGuess: true but treat it as UpdateConfigGuess: 2001-09-13 Pro: Simple upgrade path from the existing system, still flexible enough for us to add support for those funky 128bit config.guess versions and libtool updates which supports OS X 10.7 or whatever ;). Very convenient to use. Con: If we include a specific config.guess version once, we may potentially have to keep it forever, for backward compatibility. We could mitigate it by including code which tells fink that e.g. anything using config.guess 2001-09-13 can safely also use 2001-11-10. Also, this retains the somewhat special UpdateFOO fields, with the implied complexity. Personally, I prefer approach (1). Cheers, Max ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
