Re: [Fink-devel] new gettext and libiconv
I want --enable-extra-encodings. I have updated the gettext and libiconv packages: the new versions are currently in experimental/dmrrsn/base if anybody would like to help test. For gettext, in addition to bringing the program to the latest version, the division into splitoffs has been refactored to more closely match the packaging advice given by the upstream authors. One effect of this is that libgettext3 can be built without having the expat library installed, which will improve bootstrapping once libgettext3 moves into the list of essential packages. The libraries which depend on expat are now in the libgettextpo2-shlibs package (a splitoff of the new gettext-tools package). For libiconv, we now build a private copy of gettext during the compilation of libiconv. This should, at long last, solve the problems people have had with building or rebuilding libiconv when the wrong combination of libiconv-dev, gettext-dev, and libgettext3- dev were present. I will move these to unstable rather soon; any testing reports would be appreciated. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext and libiconv
On Sep 6, 2005, at 10:25 AM, AIDA Shinra wrote: I want --enable-extra-encodings. Can you explain this, please? I do not understand your request. -- Dave --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext and libiconv
I want --enable-extra-encodings. Can you explain this, please? I do not understand your request. The libiconv supports some extra encodings which are disabled by default. The /usr/lib/libiconv.2.2.0.dylib is configured with --enable-extra-encodings, but the /sw/lib/libiconv.2.2.0.dylib is not. I need the encodings to process some Japanese texts. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext and libiconv
On Sep 6, 2005, at 11:04 AM, AIDA Shinra wrote: I want --enable-extra-encodings. Can you explain this, please? I do not understand your request. The libiconv supports some extra encodings which are disabled by default. The /usr/lib/libiconv.2.2.0.dylib is configured with --enable-extra-encodings, but the /sw/lib/libiconv.2.2.0.dylib is not. I need the encodings to process some Japanese texts. OK, libiconv-1.10-5, just added to the unstable tree, is configured with --enable-extra-encodings. -- Dave --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] new gettext and libiconv
Dear Fink developers, I have updated the gettext and libiconv packages: the new versions are currently in experimental/dmrrsn/base if anybody would like to help test. For gettext, in addition to bringing the program to the latest version, the division into splitoffs has been refactored to more closely match the packaging advice given by the upstream authors. One effect of this is that libgettext3 can be built without having the expat library installed, which will improve bootstrapping once libgettext3 moves into the list of essential packages. The libraries which depend on expat are now in the libgettextpo2-shlibs package (a splitoff of the new gettext-tools package). For libiconv, we now build a private copy of gettext during the compilation of libiconv. This should, at long last, solve the problems people have had with building or rebuilding libiconv when the wrong combination of libiconv-dev, gettext-dev, and libgettext3- dev were present. I will move these to unstable rather soon; any testing reports would be appreciated. Thanks, Dave --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
On Mar 5, 2005, at 10:01 PM, Tony Arnold wrote: Hi All, Peter O'Gorman wrote: | I really wish I could propose some magic that would make everyone happy in | the upgrade process, but I can not. Is package refactoring something that's planned for the future? I've hit this a couple of times before, and the response has always been don't rename/restructure packages that are in wide use (and rightly so given the current situation), but this problem is unlikely to disappear... This is a general issue with the fink system: once a package is published and other packages depend upon it, they expect it to continue to provide the same functionality forever. The case at hand is tricky. For quite good reasons, it is being proposed to move some of the executable files out of the gettext-bin package and into a new package (gettext-tools). Since quite a number of packages already declare Depends or BuildDepends on gettext-bin, how is this upgrade to be handled? Here's one possible strategy. Step 1: Create a gettext-tools package for the current gettext, which contains only the exectables which will be moving, and which Replaces: gettext-bin That way, users who install it see no change in the set of exectuables on their system, unless they subsequent remove gettext-tools without reinstalling gettext-bin. Step 2: add gettext-tools to every package which Depends or BuildDepends on gettext-bin. Step 3: install the new libgettext3 with the new layout. The reason for doing things in this order is so that during the upgrade process itself, users have the correct executables even while other packages are being updated. Comments? Other ideas? -- Dave --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
On 08 Mar 2005, at 16:00, David R. Morrison wrote: The case at hand is tricky. For quite good reasons, it is being proposed to move some of the executable files out of the gettext-bin package and into a new package (gettext-tools). Since quite a number of packages already declare Depends or BuildDepends on gettext-bin, how is this upgrade to be handled? Here's one possible strategy. Step 1: Create a gettext-tools package for the current gettext, which contains only the exectables which will be moving, and which Replaces: gettext-bin That way, users who install it see no change in the set of exectuables on their system, unless they subsequent remove gettext-tools without reinstalling gettext-bin. Step 2: add gettext-tools to every package which Depends or BuildDepends on gettext-bin. Step 3: install the new libgettext3 with the new layout. The reason for doing things in this order is so that during the upgrade process itself, users have the correct executables even while other packages are being updated. Looks excellent, and very safe. The only alternatives I would consider are A) to simply replace the deps on gettext-bin by deps on gettext-tools : - there are extremely few pkgs that do depend (or build-depend) on gettext-bin; a quick grep for gettext in /sw/bin yields only the following candidates to check further (several or most of them are probably false positives): autoconf automake centericq gnome-blog gnomemeeting gtk-doc meld mftrace pybliographer reportbug Those can easily be checked individually, and would leave extremely few errors - The advantage I might see is that else superfluous depends tend to stay very long in the distribution. and/or B) To accelerate the migration, do step 3, then A) above _ so everybody will be forced to upgrade gettext. Jean-François --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 8, 2005, at 10:00 AM, David R. Morrison wrote: On Mar 5, 2005, at 10:01 PM, Tony Arnold wrote: Hi All, Peter O'Gorman wrote: | I really wish I could propose some magic that would make everyone happy in | the upgrade process, but I can not. Is package refactoring something that's planned for the future? I've hit this a couple of times before, and the response has always been don't rename/restructure packages that are in wide use (and rightly so given the current situation), but this problem is unlikely to disappear... This is a general issue with the fink system: once a package is published and other packages depend upon it, they expect it to continue to provide the same functionality forever. The case at hand is tricky. For quite good reasons, it is being proposed to move some of the executable files out of the gettext-bin package and into a new package (gettext-tools). Since quite a number of packages already declare Depends or BuildDepends on gettext-bin, how is this upgrade to be handled? Here's one possible strategy. Step 1: Create a gettext-tools package for the current gettext, which contains only the exectables which will be moving, and which Replaces: gettext-bin That way, users who install it see no change in the set of exectuables on their system, unless they subsequent remove gettext-tools without reinstalling gettext-bin. Step 2: add gettext-tools to every package which Depends or BuildDepends on gettext-bin. Step 3: install the new libgettext3 with the new layout. The reason for doing things in this order is so that during the upgrade process itself, users have the correct executables even while other packages are being updated. Comments? Other ideas? The Best way to find the correct builddepends is to not add gettext-tools to the packages and try to build (like during the bindist). The smoothest upgrade is to add the gettext-tools as builddeps to everything that builddeps gettext-bin. Not as many things need -tools though. It's used more for processing/creating language files than for normal package building (which just copies those files). - -chris zubrzycki - - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 Security Is A Series Of Well-Defined Steps... chmod -R 0 / ; and smile :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iEYEARECAAYFAkIt62YACgkQ+/mCMqKrwHDPWACgzRlB6Yy1mWDfxO8jUQKzEabS YBsAoN0IuuXbVq2YRNUiN77RR8TMW1f0 =Asn1 -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
Hi Chris, Cf below for an additional reason to revert to the layout of the current gettext pkg (ie, -dev containing only the headers, *.a, *.la, and the final .dylib links, and all executables in /sw/bin). Further. I'm sure that in that case all switching problems disappear... (I'm basically just arguing for maintaining strictly fink's traditional distinction between -dev and friends, not necessarily against further splitting up -bin (or even the others) according to a -Tools vs -Runtime distinction _ though I see little benefit to the latter as compared to the likely additional cost) Best, Jean-François On 04 Mar 2005, at 19:45, Jean-François Mertens wrote: On 03 Mar 2005, at 17:06, Chris Zubrzycki wrote: As per drm's recommendation, I followed the guidelines in the new gettext package, and made 2 splitoffs: Runtime tools, and Build tools. The Runtime tools i made into a library package and a binary package, and I left all the development tools in the development package. There is one thing, and that is that the build depend only utils for building other packages with gettext are now in the -dev, not in -bin. This is not a problem, as all packages that depend on the -bin also builddepend on the -dev. But it makes it impossible for other packages to respect the BuildDependsOnly of libgettext3-dev. A couple of examples, among pkgs currently in fink : _ autoreconf calls autopoint _ cicqsync (centericq) calls gettextize _ intltool-update (intltool) calls xgettext _ pozilla.sh (gtranslator) calls msgmerge, msgfmt _ xgettext.pl (locale-maketext-lexicon-pmXYZ-bin) calls xgettext Also it makes it difficult to detect, in every new version, hidden dependencies between -bin and -dev, [eg the following I stumbled upon: the executable /sw/lib/gettext/user-email (in -dev) sources /sw/bin/gettext.sh (from -bin)]. Adding any such dependency would make switching back and forth even harder. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
I disagree here, -dev should be all thing that should never be depended on and that are needed to build pkgs. ie: %p/bin/%n-config should ALWAYS be in the -dev pkg. I personally think we should find a way to correct this in gettext and make it done, even if it becomes a multi step solution. I haven't had time to read or test any of this. But saying no binary belongs in -dev pkg is not valid and will break all hopes of shlibs support in the future. but if we need to make an other split for -dev-bin or what ever -dev should depend on it at least so one only needs a builddep on the -dev. Which will go against BuildDependsOnly, but i think it is necessary. --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 6-Mar-05, at 9:55 AM, Jean-François Mertens wrote: Hi Chris, Cf below for an additional reason to revert to the layout of the current gettext pkg (ie, -dev containing only the headers, *.a, *.la, and the final .dylib links, and all executables in /sw/bin). Further. I'm sure that in that case all switching problems disappear... (I'm basically just arguing for maintaining strictly fink's traditional distinction between -dev and friends, not necessarily against further splitting up -bin (or even the others) according to a -Tools vs -Runtime distinction _ though I see little benefit to the latter as compared to the likely additional cost) Best, Jean-François On 04 Mar 2005, at 19:45, Jean-François Mertens wrote: On 03 Mar 2005, at 17:06, Chris Zubrzycki wrote: As per drm's recommendation, I followed the guidelines in the new gettext package, and made 2 splitoffs: Runtime tools, and Build tools. The Runtime tools i made into a library package and a binary package, and I left all the development tools in the development package. There is one thing, and that is that the build depend only utils for building other packages with gettext are now in the -dev, not in -bin. This is not a problem, as all packages that depend on the -bin also builddepend on the -dev. But it makes it impossible for other packages to respect the BuildDependsOnly of libgettext3-dev. A couple of examples, among pkgs currently in fink : _ autoreconf calls autopoint _ cicqsync (centericq) calls gettextize _ intltool-update (intltool) calls xgettext _ pozilla.sh (gtranslator) calls msgmerge, msgfmt _ xgettext.pl (locale-maketext-lexicon-pmXYZ-bin) calls xgettext Also it makes it difficult to detect, in every new version, hidden dependencies between -bin and -dev, [eg the following I stumbled upon: the executable /sw/lib/gettext/user-email (in -dev) sources /sw/bin/gettext.sh (from -bin)]. Adding any such dependency would make switching back and forth even harder. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
so they are a builddep and a runtime dep...if so why not just keep them in -bin and builddep and dep on it/them? --- TS http://southofheaven.org Chaos is the beginning and end, try dealing with the rest. On 6-Mar-05, at 11:06 AM, Jean-François Mertens wrote: On 06 Mar 2005, at 18:07, TheSin wrote: I disagree here, -dev should be all thing that should never be depended on and that are needed to build pkgs. ie: %p/bin/%n-config should ALWAYS be in the -dev pkg. Of course ! Here there is no -config or .pc file _ that's why it wasn't mentioned; the list was just suggestive of the principle you express. If you look at the examples given, they are legitimate Dependencies. Jean-François --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
On 06 Mar 2005, at 19:58, TheSin wrote: so they are a builddep and a runtime dep...if so why not just keep them in -bin and builddep and dep on it/them? Wonderful to see how we always agree ... JF --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
'almost done, no?' Yes _ looks so. Congratulations ! From a first look, small points: 1) in gettext-emacs, the rm %i/share in the InstallScript leads in the PostInstallScript to: install/gettext-tools: byte-compiling for emacs21 cp: cannot stat `/sw/share/emacs/site-lisp/gettext-tools/po-mode.el': No such file or directory cp: cannot stat `/sw/share/emacs/site-lisp/gettext-tools/po-compat.el': No such file or directory 2) gettext-tools (xgettext) should depend on expat-shlibs (plus presumably the corresponding builddeps). 3) gettext-bin should depend on libgettext3 (= 0.14-1) 3) I don't know what to think about the superfluous dependencies on gettext-bin and gettext-tools that you add in libgettext3-dev: presumably they are meant to simplify usage, but - they are not there in the current version (correctly I think), so no current pkg can 'depend' (english) on such superfluous dependencies. - they might make switching MUCH HARDER (eg when also gettext15 comes up) To me, anyway about any pkg builddepends on gettext-tools (checking for msgfmt etc); while a small fraction wants to link with (a specific version of) libgettext3 and needs therefore to further buildepend on (that version of) libgettext3-dev. There is no reason a priori that it would need the same version of msgfmt etc.. We should probably rather think of the gettext-tools as commands that happen to be used in most builds, just as so many other commands (say, sed), and treat them in the same way: completely independently of the issue of linking with the gettext shlibs. Best, Jean-François --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Zubrzycki wrote: | Any thoughts/suggestions? Well, we need the new gettext, I agree, but we also need for users to be able to run a successful selfupdate and update-all. It does not seem that the package which you have put into your experimental dir would support that. We *must* find a solution to this issue before any new gettext package is committed to unstable. I really wish I could propose some magic that would make everyone happy in the upgrade process, but I can not. I hope that someone else has had their magic wand upgraded recently and can propose a solution. Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQinPO7iDAg3OZTLPAQID7QP+ONpe+747eyICBr2qMCP/wgng1+QKmE/H gk3Eul3PjlC6Tkd9Wp4esL774hd7EfGGZ6yRa4hVBlGE6uDselVC33VyXKuDJjS6 WBm9fFWXzizu0c9WbU+sRhg3xEG+Zjhy4PL0zw/Sv/7yYIy9/877cTvOUXggGeG6 bzeWmm+N5Sw= =U8HE -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Peter O'Gorman wrote: | Chris Zubrzycki wrote: | | | Any thoughts/suggestions? | | Well, we need the new gettext, I agree, but we also need for users to be | able to run a successful selfupdate and update-all. It does not seem that | the package which you have put into your experimental dir would support | that. We *must* find a solution to this issue before any new gettext | package | is committed to unstable. | | I really wish I could propose some magic that would make everyone happy in | the upgrade process, but I can not. | If you would give me enough time to plan this upgrade. If you can provide a clear path how to manage such an upgrade by hand, then it would be no problem to arrange ourselves with our community. Should we not be able to find an automatic solution, I can only offer to handle this for all of us in a manner that should be acceptable to you as developers and our community. I am sure I could convince the media to tag along. - -d -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.6 (Darwin) iD8DBQFCKePQPMoaMn4kKR4RA1WjAKCBsTXLhATCFtNFlApuZRaQlUss4ACfWID6 EXjJEt3eIxlgd/+HNR64MZk= =0mAT -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] new gettext
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have prepared a new gettext package to use, based on the latest code (jan 04). It's called libgettext3 and is in exp/beren12. As per drm's recommendation, I followed the guidelines in the new gettext package, and made 2 splitoffs: Runtime tools, and Build tools. The Runtime tools i made into a library package and a binary package, and I left all the development tools in the development package. There is one thing, and that is that the build depend only utils for building other packages with gettext are now in the -dev, not in -bin. This is not a problem, as all packages that depend on the -bin also builddepend on the -dev. The problem comes when switching back and forth between the -dev splitoffs, since the new -bin does not contain the developmental utilities, and they are not in the old -dev. I have updated the old gettext-dev package to include the few dev utilities in it, but it would be just as easy to move all the binaries back to -bin. Any thoughts/suggestions? - -chris zubrzycki - - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iEYEARECAAYFAkInNh4ACgkQ+/mCMqKrwHAr0gCg3Fn8todTKSbbnftlOY86RFmy qwgAnRIuFsjyw7ctBUua9Av65uXvaGS7 =h4HE -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new gettext
Hi Chris, On 03 Mar 2005, at 17:06, Chris Zubrzycki wrote: I have prepared a new gettext package to use, based on the latest code (jan 04). As you had asked to test it, I've been using it since one month, rebuilding everything using gettext3 (and readline - readline5, gdbm - gdbm3, netpbm - netpbm10, guile - guile16 ) It works like clockwork _ except, as you note below, the switching back and forth: that is why I preferred to use only the new one. One tempting possibility might be to do as you did so nicely for ncurses: immediately phase the old version out (and probably at the same time take care of the other pkgs mentioned abve) It's called libgettext3 and is in exp/beren12. As per drm's recommendation, I followed the guidelines in the new gettext package, and made 2 splitoffs: Runtime tools, and Build tools. The Runtime tools i made into a library package and a binary package, and I left all the development tools in the development package. There is one thing, and that is that the build depend only utils for building other packages with gettext are now in the -dev, not in -bin. This is not a problem, as all packages that depend on the -bin also builddepend on the -dev. The problem comes when switching back and forth between the -dev splitoffs, since the new -bin does not contain the developmental utilities, and they are not in the old -dev. I have updated the old gettext-dev package to include the few dev utilities in it, but it would be just as easy to move all the binaries back to -bin. Any thoughts/suggestions? If the 2 have to coexist, and one has to switch back and forth, I might favour the latter option: about every pkg builddepends on there being some msgfmt etc : so we would have builddepends on libgettext3-dev everywhere. The alternative would allow to builddepend on libgettext3-dev only for pkgs that need to link with one of the libs. Best, Jean-Francois PS: concerning dependencies : 1) gettext-bin depends on libgettext3, libiconv 2) libgettext3-dev depends on libgettext3, libiconv and expat-shlibs (xgettext) _ the latter is no problem: expat has no deps 3) libiconv-bin depends on libgettext3 (formally this might require a separate libiconv-bootstrap pkg, that does not depend on gettext, and is later replaced by the real libiconv) 4) To finish with this, libiconv badly depends on itself: gcc iconv.o -o iconv ../srclib/libicrt.a -L/sw/lib /sw/lib/libintl.dylib /sw/lib/libiconv.dylib -lc When one has to rebuild all ones pkgs, with the installed ones being broken, eg by a change in libSystem, such things don't help... --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
