UPDATING 20130904 entry issues
Guido Falsi
mad at madpilot.net
Wed Sep 11 19:27:12 UTC 2013
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 at madpilot.net>
More information about the freebsd-ports
mailing list