Date: Wed, 11 Sep 2013 21:27:02 +0200 From: Guido Falsi <mad@madpilot.net> To: mexas@bris.ac.uk Cc: freebsd-ports@freebsd.org Subject: Re: UPDATING 20130904 entry issues Message-ID: <5230C406.3000709@madpilot.net> In-Reply-To: <201309111432.r8BEWe0Z001742@mech-cluster241.men.bris.ac.uk> References: <201309111432.r8BEWe0Z001742@mech-cluster241.men.bris.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/11/13 16:32, Anton Shterenlikht wrote: > ports/UPDATING from 20130904 has: > > # pkg query %ro libiconv >ports_to_update > # pkg delete -f libiconv > # cat ports_to_update | xargs portmaster > > So I have to delete a port on which >250 other > installed ports depend. After that I have *many* > unusable ports until the portmaster completes > the rebuilding, which, on my boxes, means days. > > In addition, my experience, at least on ia64, sparc64 > and amd64 is that such large updates never go smoothly. > > So, is it possible to reverse the procedure, and > update all ports which depend on libiconv before > deleting it? I'm thinking about the recommended > procedure for using "make delete-old-libs" for the > base OS. There new port builds automatically pick > the newever version of the shared lib. When the old > version is no longer used by any ports it can be > removed. First of all note that this affects only 10-CURRENT users. Since the libc iconv implementation has been enabled by default systems left "as is" end up with two iconv implementation installed after upgrading the base system. This means two conflicting iconv.h file (one in usr and one in local), one implementation living in libc(requiring no -l flags) and one living in libiconv.so in local/lib, requiring an ld -liconv flag to link against. As you know ports just bundle upstream ports with a few patches. Most third party build systems simply do not account for this kind of double iconv situation. various ports were already failing due to this. Some were also doing the right thing, others were confuse, including iconv.h from /usr/include but trying to link to libiconv.so in local, which cannot work. Some ports build systems had a "if FreeBSD" conditional somewhere forcing use of the -liconv flag for us, which will force use of the old library, which could work, if the correct include file is taken, but will not allow migration. Only way to make it work without need to rework a few thousand ports was to make the system have only one iconv implementation present, and fix the not too many ports which hardcoded -liconv and similar things in their build systems. This means that keeping both implementations installed isn't a good solution and a non started for packages building. Please note that adding a stub libiconv.so library to base isn't a good solution, your binaries would end up linking to it, and you would anyway have to recompile those when removing it. You can't make a parallel with new libraries, our iconv implementation isn't a newer version of the same library. it's a completely different implementation which just happens to implement the same functionality. It's a different library(bundled in libc) completely. And there is also a whole big problem about libtool archives, which preserve build flags from before, which need to be regenerated(done when reinstalling the port) not to bite you in the future. I sincerely don't know how to force fixes to appear in the dozens or more build systems the software in the ports collection use. In an ideal world all the software's build systems would detect two iconv implementations and prefer the OS provided one if present(this would also require a worldwide consensus that the OS provided one is the "best" one). some in fact even do this, but many others (some are dependencies of hundreds of others) don't preferring the ports provided one, or simply getting confused and failing to build, and we have to cope with this. Anyway, while the update can't be undone save by using system backups, you can remove the libiconv port, update ports, and if something goes wrong you can reinstall the libiconv port, ports compiled against it will start to work again and recompiled ones will keep using the new implementation. Remember to remove the IGNORE line in the iconv port if you want to reinstall it. > > Is it not possible to tell ports to first check > for libiconv in base, and if it is not there, > then install/use one from ports? As explained above, ports are external software each using it's own build system. Some are able to do what you describe with two conflicting implementations, most do the right thing when just one implementation is present, and just a few required fixing. Allowing the whole ports tree to work with both conflicting implementations present would have been a gigantic endeavor requiring modifying or revamping many ports build systems. Most probably would have taken a much longer time during which things would have been much more broken. -- Guido Falsi <mad@madpilot.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5230C406.3000709>