Am 10.11.2009 um 19:22 schrieb Martin Costabel:

> Max Horn wrote:
> []
>> (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.
> []
>
>> Personally, I prefer approach (1).
>
> Ther is a practical problem with this approach: It requires real
> maintainer work, not just cosmetics. But if you look at the packages
> that use Update fields (a quick grep shows more than a hundred with
> UpdateConfigGuess and more than 50 with UpdateLibtool and even a dozen
> with UpdateLibtoolInDirs), you see that most of them are very old and
> haven't really been maintained for a long time. It will be difficult  
> to
> do more than cosmetic changes in all of these.

Indeed, thank you for clarifying this. I was somehow under the (wrong)  
impression that there are fewer affected packages :/. (Though note  
that for UpdateLibtoolInDirs, looking at the grep output closer  
reveals that only 7 packages in unstable actually use it ;). Still too  
many, of course).       

Well, then let me propose approach (1'): We don't touch "UpdateFOO" at  
all, but deprecate it (in the docs, and maybe the validator should  
print "this is a deprecated field, don't use it"). Code which needs to  
update config.guess etc. uses one of the approaches suggested in (1)  
and in other emails in this thread, but *not* UpdateFOO.


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
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to