ports libiconv -> base iconv

[Guido Falsi]

On 08/31/13 22:25, Boris Samorodov wrote:
> 31.08.2013 23:17, Boris Samorodov пишет:
>
>> (let's change the subject to a more apropriate)
>>
>> 31.08.2013 18:28, Guido Falsi пишет:
>>
>>> I have spent a few hours experimenting and produced this PR:
>>>
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/181693
>
> Guido, here are some notes about your PR and patches.
>
> There are two patches. Seems that the second one is not needed.
> Is it?

Unluckily it was a little mangled by gnats, it's one single patch, but 
gnats split it due to a piece it was not understanding.

I'm creating another updated patch I'll send as a followup avoiding 
parts(props changes) which could confuse gnats!

>
> I know it's very time consuming and thanks for your work, but...
> I would not recommend to include at the patch changes not linked
> with the matter. Ports are changing (headers, optionsNG, LIB_DEPENDS
> syntax, etc.) -- it may be extreamly difficult to you to create a patch
> which is ready to test by portmgr, then do some changes to the patch
> and then finally to get a patch which is ready to commit. Actually it
> doesn't apply _now_ (several hours after submitting a PR!), not to say
> in a week or two... BTW, failed hunks are almost all have number 1, so
> headers are changing rapidly.

This is the first time I work with such a big patch, I'm not sure what 
is the best way to work with it.

Maybe the exp run could be run against a specific revision of the ports 
tree with which the patch applies. This could be a way to get some 
result even if not against the latest tree, it would be just a few days 
behind at most.

>
> And I have a question about the amount of ports at your patch.
> I grepped the first patch for "Index" and got 97 files. So you patch
> about a hundred ports. Then I grepped the portstree makefiles for
> "iconv" and got 778 ports (let's assume some are false positives, so
> actual amout may be aroud 700). So the question is: are those 600
> untouched ports currently ready to use base iconv (well, after bmk
> changes)? If yes, then our portstree is at a good state! (Well, maybe
> those that just have USES=iconv are ready?)

I mainly centered my attention on the ones with USES=iconv, which were 
the ones I saw failing most, since most of those have pieces in the 
Makefiles to force the ported software to link against libiconv.so in 
/usr/local. I asked for the exp run for the specific reason I'd like to 
get a better idea of what is the shape of our ports tree, and to get a 
better understanding of how hard the task of switching to lib iconv 
could really be.

 From the subset of ports I have tested this (around 1200, mainly the 
ones I use in some way) it looks to me that our ports tree isn't in bad 
shape. On the 1200 ports I use I had to patch just a few, around 12. 
Most ports seem to just do the right thing anyway. In fact if it wasn't 
for cups and a pair of other high profile ones failing I wouldn't have 
noticed the problem at all!

>
> Sorry, I did just a quick glance at the matter, so you may understand it
> better. I beg your pardon if I'm terribly wrong. Thanks!
>

It is quite possible it's me being terribly wrong. That's what I'm 
trying to ascertain. :)

I'm just at the first steps in this, I still need a few days to test it 
all completely, and study a correct update path for all users.

-- 
Guido Falsi <madpilot at FreeBSD.org>