[...]

>>> 
>>> 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.

Aye, makes sense.

> 
> For example, next gnome-core suite will be completely libgettext8.

Nice.


> 
>>> 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.

True enough.

But then, of course not only abandoned packages suffer from this issue. And I 
don't see where we actively tell packagers to switch? Maybe I am just 
overlooking something, though?
E.g. our old "gettext" package is not even marked obsolete, and if I was 
looking for gettext, well, it would be the first thing for me to see... :)  
Don't get me wrong, I am not asking for it to be marked as such. I just want to 
point out that it's not trivial for a maintainer to figure out that they 
shouldn't use it.
And then, at least in my days, most people learned packaging by example -- they 
looked at existing .info files and copied what they saw. So the more pkgs still 
using gettext or libggettext3 out there, the more new ones will be written 
using them, right?


IMO we have a small communication problem there. We want people to make a 
switch, but we are not loudly telling them to do so. Granted, I don't believe 
we'll see a huge rush of maintainers changing their packages, but if we aren't 
even trying to get them to do this, we can't complain when they aren't doing 
anything :-).

So, how about adding a Wiki page / a page in the packaging docs, which tells 
people to use libgettext8 "when appropriate", or at least libgettext3, and to 
avoid gettext? 
Maybe there are more packages, and then they should be mentioned there, too?
I am willing to write such a page, if it is deemed a good idea. I'd tend to put 
it on the wiki, at least at first, so that people can edit the text until it's 
good.

As a second step, once that text is done, we should send out an announcement of 
this policy change, with a pointer to the webpage with details.


Anyway, this discussion already taught me how to handle gettext for my own 
packages from now on, for which I am grateful :-)


Cheers,
Max
------------------------------------------------------------------------------
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
[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