Date: Sat, 14 Dec 2013 15:29:30 +0100 From: Guido Falsi <madpilot@FreeBSD.org> To: Eygene Ryabinkin <rea@freebsd.org> Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: 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... Message-ID: <52AC6B4A.2080407@FreeBSD.org> In-Reply-To: <czUZEkbivVxkY5vmYTxYHOhjVJ4@W4hAcbyY3boCl2ecg4/u9JA8hSY> References: <201309041806.r84I680e048857@svn.freebsd.org> <czUZEkbivVxkY5vmYTxYHOhjVJ4@W4hAcbyY3boCl2ecg4/u9JA8hSY>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/14/13 11:51, Eygene Ryabinkin wrote: > Wed, Sep 04, 2013 at 06:06:08PM +0000, Guido Falsi wrote: >> Author: madpilot >> Date: Wed Sep 4 18:06:07 2013 >> New Revision: 326307 >> URL: http://svnweb.freebsd.org/changeset/ports/326307 >> >> Log: >> - Make ports use the libc provided iconv implementation on 10-CURRENT >> after r254273 >> - Fix a bunch of ports to properly work after this >> - Mark converters/libiconv as IGNORE for systems with iconv in libc >> >> Reviewed by: bapt >> Approved by: portmgr (bapt) >> Discussed with: bapt, bsam (who both contributed ideas and code) > [...] >> Modified: head/UPDATING >> ============================================================================== >> --- head/UPDATING Wed Sep 4 18:04:48 2013 (r326306) >> +++ head/UPDATING Wed Sep 4 18:06:07 2013 (r326307) >> @@ -5,6 +5,35 @@ they are unavoidable. >> You should get into the habit of checking this file for changes each time >> you update your ports collection, before attempting any port upgrades. >> >> +20130904: >> + AFFECTS: 10-CURRENT users with any port depending on converters/iconv >> + AUTHOR: madpilot@FreeBSD.org >> + >> + 10-CURRENT after r254273 (committed on August 13, 2013) has an >> + implementation of iconv enabled by default in libc. >> + >> + Due to this change some major overhauling of the ports tree has >> + been necessary to move the ports to using that implementation. >> + >> + People using pkgng should have little problems, "pkg upgrade" >> + will update all sofware to not depend on libivconv anymore, once >> + updated packages are available. Please make sure to perform a >> + "pkg autoremove" after that and check that libiconv is correctly >> + removed by it. >> + >> + If you are using ports the update requires some manual intervention. >> + The following procedure should be followed: >> + >> + # pkg query %ro libiconv >ports_to_update >> + # pkg delete -f libiconv >> + # cat ports_to_update | xargs portmaster >> + >> + or: >> + >> + # pkg query %ro libiconv >ports_to_update >> + # pkg delete -f libiconv >> + # cat ports_to_update | xargs portupgrade -f > > This seem to have many problems: after libiconv is removed, we have no > dynamic library. This creates some problems: if any ports that are > needed for builds of another packages (libxml, for example, that is > needed to generate documentation) will be built after the ports that > need them (and this seem to be the case), it won't work at all: tools > will lack libiconv and fail. Had experienced this with portupgrade > way; needed to rinse and repeat it after manual 'make all deinstall > install clean' for affected ports. > > Most likely, there are some ports that lack build-time dependencies > on ports that need iconv, so portupgrade's ordering works, but it > lacks the proper input information. The system I am referring to > is built from ports with custom OPTIONS, so, probably, these problems > aren't being catched by poudriere and alike. Unfortunately, I was > in need to be able to quickly, so priority was to bring the system > to the working state, thus no precise information which ports were > problematic, sorry. > > For the other system, me doing "mv > /usr/local/include/iconv.h{,.orig}", upgrading all ports after that > and removing libiconv after that works much better: ports that detect > the presence of iconv will pick iconv from base, since there will be > no include file in /usr/local/include. > > Probably the UPDATING entry needs to be modified, since ports-only > users could suffer from the same problems as I were. > As stated earlier this was an emergency commit. After the iconv implementation was enabled by default in base many ports build systems were really confused by the presence of two iconv implementations (one in libc and one in libiconv, with tyo iconv.h files, one in /usr/include and one in /usr/local/include). This solution allowed almost all ports (there were various followup commits needed to fix some ports which slipped by this first bunch) to build again using base iconv. before this commit many ports were already broken, some were ports depended upon by a lot of other ports (for example, glib20). 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 NOTE: I'd suggest excluding the libiconv port (-x libiconv for portmaster, not sure about portupgrade) 3) pkg delete libiconv (should have no dependencies by now) 4) rm /usr/local/include/iconv.h.old Have I got it right? I'm willing to review my UPDATING entry but I need feedback to bee sure about what I'm putting there. Thanks for reporting your findings! -- Guido Falsi <madpilot@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52AC6B4A.2080407>