Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
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
Re: [Fink-devel] 10.6 upgrade document
Hi Alexander, great work! One tiny remark: Am 10.11.2009 um 04:11 schrieb Alexander Hansen: [...] liRun the command prefink install perl588-core/pre to replace the version of perl which Apple changed during the OS X upgrade, in case you have Fink packages which depend on it./li This sounds as if Fink would replace a system component, i.e., it sounds quite scary. But we doN't really do that (or do we??). Also, while I like when people tell me *why* I have to perform certain steps during an upgrade, they can at the same time be distracting. And these explanations are missing in the other steps. So, why not just change this to: liRun the command prefink install perl588-core/pre./li Or if you want to give some explanation, maybe: liRun the command prefink install perl588-core/pre. This avoid potential issues with any packages installed by you which require this older version of Perl./li 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
Re: [Fink-devel] 10.6 upgrade document
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Horn wrote: Hi Alexander, great work! One tiny remark: Am 10.11.2009 um 04:11 schrieb Alexander Hansen: [...] liRun the command prefink install perl588-core/pre to replace the version of perl which Apple changed during the OS X upgrade, in case you have Fink packages which depend on it./li This sounds as if Fink would replace a system component, i.e., it sounds quite scary. But we doN't really do that (or do we??). Also, while I like when people tell me *why* I have to perform certain steps during an upgrade, they can at the same time be distracting. And these explanations are missing in the other steps. So, why not just change this to: liRun the command prefink install perl588-core/pre./li Or if you want to give some explanation, maybe: liRun the command prefink install perl588-core/pre. This avoid potential issues with any packages installed by you which require this older version of Perl./li Cheers, Max Sounds good. I pasted directly from the item on the news page, so that's where the scariness came from. - -- Alexander Hansen Fink User Liaison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr5gEAACgkQB8UpO3rKjQ8c3ACbBiFnySQ2KbwdfhUZihkZnZSn sx4AoJFJOn1dhpSsqjdHt4pXBSzQu4iu =ywn2 -END PGP SIGNATURE- -- 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
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 Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
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. -- Martin -- 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
[Fink-devel] tk file dialogs broken?
Is anyone else seeing this problem in current fink 10.5 unstable on powerpc-apple-darwin9.8.0? I am finding that both pymol-py25 and sparky-py25 are both producing tk file dialogs which contain no files or folders (for the open dialogs in both programs). I don't believe this is a system problem as the obsolete pymol-x11 binary from pymol.org works fine. I have another dual G5 which hasn't been updated as recently which isn't showing the problem. Both are running Xquartz 2.4.0. The only other difference is that the problem machine has Xcode 3.1.4 and the working machine has Xcode 3.1.3. Jack -- 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
Re: [Fink-devel] [Fink-beginners] kdegraphics3-base installation fails
Alexander Hansen wrote: Umut Yildiz wrote: Hi, I am trying to install kile with fink but I could not succeed at the last step. It is giving me the following error. What can I do to fix this? [] checking for rpath... yes checking for KDE... configure: error: in the prefix, you've chosen, are no KDE libraries installed. This will fail. [] Check /sw/src/fink.build/kdegraphics3-3.5.10-1/kdegraphics-3.5.10/config.log and look for where it says checking for KDE. I have the following: configure:31714: checking for KDE configure: 31767: /sw/include/ksharedptr.h taking that configure: 31797: /sw/lib/libkio.la taking that configure: 31815: /sw/lib/kde3/plugins/designer/kdewidgets.la taking that configure:31888: result: libraries /sw/lib, headers /sw/include This is worth keeping for the record, as the first documented case where *.la files are necessary and where the advice to remove all *.la files breaks things. Now why that configure script is doing this, and if it could be asked to cease and desist, is another question. It takes its cue from admin/acinclude.m4.in, a general kde thing, it seems. -- Martin -- 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
