On Mon, Mar 15, 2010 at 11:07:05AM -0400, Alexander Hansen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/15/10 10:58 AM, Max Horn wrote: > > > > Am 15.03.2010 um 15:42 schrieb Alexander Hansen: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 3/15/10 10:39 AM, Max Horn wrote: > >>> Hi there, > >>> > >>> can somebody advise me on libgettext3 vs. libgettext8 -- in particular, > >>> for new packages (and when revising existing packages of mines), should I > >>> stick with libgettext3, or are we going to gradually migrate to > >>> libgettext8 ? Is there any kind of policy on this? I searched for this > >>> but could find nothing, so any pointers would be appreciated. > >>> > >>> > >>> Cheers, > >>> Max > >> > >> There's nothing formal that I know about. I think the current practice > >> is now to update to libgettext8, when appropriate, and to have new > >> packages use it (again, when appropriate), so that we can gradually > >> deprecate gettext3. > > > > And what does "when appropriate" mean? > > The package builds.
And also that we aren't doing sweeps and making updates *just* for this issue (rev-up and force rebuild to migrate), but rather when updating packages for some other reason, "may as well also switch" at that point. For example, next gnome-core suite will be completely libgettext8. > > Otherwise, I don't think it'll happen in the next couple years. For > > example, I only noticed the existence of libgettex8 by chance. So if we > > don't announce it to our package devs, they hardly will attempt to make the > > transition, right? :-) We still have a lot of packaging using the old-old "gettext" too:( Many of those are not being carried beyond 10.5, but others... This would be a good heuristic to check for long-abandoned packages that might be bit-rotten or in need of a quick update for many reasons. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ 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
