libiconv on 10.0-RELEASE

[Guido Falsi]

On 02/01/14 08:14, nano wrote:
> On 1/02/2014 6:03 PM, Guido Falsi wrote:
>> On 02/01/14 07:53, nano wrote:
>>> Seems to be some issues with it:
>>> https://forums.freebsd.org/viewtopic.php?f=5&t=44644
>>> https://forums.freebsd.org/viewtopic.php?f=5&t=44659
>>>
>>> And my problem:
>>> https://forums.freebsd.org/viewtopic.php?f=5&t=44658
>>>
>>> Can't do UPDATING: 20130904, libiconv has never been on the system.
>>>
>>> Not sure whether to allow portmaster to upgrade[*]. Pretty sure
>>> something will break if I do. What do you suggest?
>>
>> Hi,
>>
>> Since then a new commit has changed things a little, it's r341775 [1]
>>
>> It now allows libiconv to be installed by a few selected ports who
>> really need functionality not available in the base implementation of
>> iconv.
>>
>>>
>>>
>>> [*]
>>> # portmaster -adwv
>>> ===>>> All >> (4)
>>>
>>> ===>>> The following actions will be taken if you choose to proceed:
>>>          Upgrade php55-iconv-5.5.8 to php55-iconv-5.5.8_1
>>>          Install converters/libiconv
>>>          Upgrade nginx-1.4.4_2,1 to nginx-1.4.4_3,1
>>>          Upgrade owncloud-6.0.0a to owncloud-6.0.1
>>>
>>> ===>>> Proceed? y/n [y] n
>>>
>>>
>>
>>  From what I see here I think you can allow it to do that without
>> problems for now. I've seen two PRs stating problems with some ports.
>>
>> The PRs I've indicate that, after such a step, glib20 and exim fail to
>> build. These problems need fixing at present.
>>
>> This applies only to ports compiled on the live system, if one is using
>> poudriere or tinderbox they can build anyway(so binary packages have no
>> problems), this happens because when using these software each port is
>> compiled in a clean environment.
>>
>> [1] http://svnweb.freebsd.org/ports?view=revision&revision=341775
>>
>
> Hi, Guido. Thanks for your response.
>
> Not sure about this users particular situation, except that it appears
> they are experiencing some problems compiling libiconv [0]. Another user
> seems to be experiencing problems (re)installing php5x-iconv, which has
> rendered something broken [1]. This makes me reluctant to proceed with
> my upgrades for fear that similar will occur.
>
> Also, I'm not usng svn, but portsnap; don't know if it matches r341775.
>

Don't know at what time you ran portsnap, but, portsnap simply tracks 
the subversion repository, it's just a little lagged but just by one 
hour at most, so you most probably have a ports tree post r341775.

> I appreciate your advice, but I think I will wait before updating these
> ports. Hopefully things get cleaned up a bit. I would not be happy if
> something breaks.

I understand. I still have not had a good look at r341775 and have only 
built ports affected by it in poudrirere, and using them as binary 
packages, which works fine.

>
>
> [0] http://forums.freebsd.org/viewtopic.php?f=5&t=44644&p=248807#p248731
> [1] http://forums.freebsd.org/viewtopic.php?f=5&t=44659#p248806
>

I really don't know what's going on on these user's systems. The error 
logs they posted have to little backlog to have any idea about what's 
really causing the problem.

For what' I've seen php53-iconv should work fine, but if it's vital to 
you, you should then wait a little. These problems require some time and 
trials to fix.

Most of the time the problem are the ported software packaging systems 
which assume FreeBSD has no iconv implementation and expect to find 
libiconv, or are unable to cope with two iconv implementations being 
available at the same time. This requires coping with such problems one 
by one which requires a little time and can't be really managed by 
automated testing systems, since these problems show up only on live 
systems.

-- 
Guido Falsi <madpilot at FreeBSD.org>