svn commit: r326307 - in head: . Mk Mk/Uses archivers/rpm archivers/unrar archivers/unrar-iconv archivers/unzip audio/julius audio/mp3unicode audio/mpc audio/mpiosh audio/mpiosh/files audio/osd-lyr...

Guido Falsi madpilot at FreeBSD.org
Sun Dec 15 20:28:04 UTC 2013


On 12/15/13 16:34, Eygene Ryabinkin wrote:
> Sat, Dec 14, 2013 at 03:29:30PM +0100, Guido Falsi wrote:
>> That said, Your solution of renaming iconv.h could be a good idea I did
>> not think about.
>>
>> Let me understand exactly; you used a procedure like this:
>>
>> 1) mv /usr/local/include/iconv.h /usr/local/include/iconv.h.old
>> 2a) portupgrade -af		(I'm not using portupgrade, please confirm correct
>> syntax)
>> 2b) portmaster -af
>
> Actually, it was a bit different one:
>   - get a fresh copy of ports tree;
>   - 'portupgrade -a' to get the latest versions of all ports;
>     was patched libiconv's Makefile to omit IGNORE;
>   - mv /usr/local/include/iconv.h /usr/local/include/iconv.h.old
>   - 'portupgrade -fa -x libiconv'
>   - pkg delete libiconv
>
> First two phases were done to make sure that "portupgrade -fa" won't
> really upgrade anything, but will just reinstall with all port being
> up to date (so there are no unbuildable ports).  I am often sync the
> ports tree to upgrade just one or two ports, so it could be just my
> local dance that isn't nessessary.
>
> I'll try to upgrade my primary workstation with just
>   - mv /usr/local/include/iconv.h /usr/local/include/iconv.h.old
>   - 'portupgrade -fa -x libiconv'
>   - pkg delete libiconv
> and will report the outcome.

A better way to preserve old iconv is to save it in 
/usr/local/lib/compat/pkg then remove the port. It' almost the same as 
removing the iconv.h file imho.

so doing:

- cp /usr/local/lib/libiconv* /usr/local/lib/compat/pkg/
- pkg delete -f libiconv
- portupgrade -fa -x libiconv

should work the same, and should avoid references to the libiconv port 
from surviving in the pkgng database.

Are you able to test this procedure too?

I can try building a test jail for this, but that wouldn't be a good 
testcase, a live system which has been updated for months/years with 
hundreds of ports is quite different from a  test jail with just a bunch 
of freshly installed ports.

-- 
Guido Falsi <madpilot at FreeBSD.org>


More information about the svn-ports-head mailing list