Hey, kyak, first of all - I have to admit I have mixed feelings about your mail :)
Rather than speculating in IRC about what happened I would have much more appreciated finding an email on the OpenWrt mailing list, containing some questions and/or hints what got done the wrong way from your point of view. Also the mail this is a reply to is more speculation presented as facts than the real story. That's no offense - I'd like to call for more communication at this point - this pretty much includes myself, too! Despite that, I totally understand caused resentment and would like to clarify a bit about what happened and is going to to happen regarding iconv / intl. Here's the full story about the stubs: We (OpenWrt) sticked to some quite old versions which are part of or used by the autotools suite, such as libtool, autoconf, automake, etc. We sticked to these versions (and the design using them) because it worked, at least somehow. These autotools make the job of maintaining a toolchain like OpenWrt is (or OpenEmbedded or any other with lot's of different packages) _very_, _very_ _difficult_. That's the nicest statement I'm able to give regarding this suite of tools - don't get me started :) However some tasks we postponed because they depended on massive updates and changes affecting lot's packages using autotools needed to get done now. So we tried to implement these massive changes - and - as expected - broke a lot. These changes were done in trunk/ and unfortunately there were needed changes in packages/ as well. Since packages/ is not branched but used by the release backfire (which we're using for the NanoNote image) _and_ trunk, changes in packages/ affect the release backfire using software from packages/ as well. After we completed the redesign and upgrade (which was hell of work, mostly done by Jow (xMff)!) we noticed that the behavior of generated Makefiles and configure-scripts changed regarding libintl and libiconv - every piece of software _able_ to use libiconv / libintl now _linked_ and _used_ them, instead of only software which definitely _requires_ them. That's why we created the stub files to be able to feed these stubs to the autotools / configure-scripts / Makefiles instead of using the full-blown ones. That broke software is _really_ needing the functionality iconv / intl provide which and isn't satisfied with just the stubs. == What are we going to do? We will create another so called "feature flag". This will let you choose between using the "stubs" or the full versions. The NanoNote will use the full-version of both and everything should work again. This will happen upcoming week. In the medium term we will try to handle that in a more elegant way, e.g. letting packages export whether they're able to run with just the stub or they do need the full version. Best case would be creating a minimal version which could be used by all software requiring iconv, but being small enough to make the stub obsolete. Cheers and have a nice week! mirko On Thu, 2011-01-06 at 18:02 +0300, kyak wrote: > Hi! > > As some of you already know, libiconv and gettext (libintl) are now stubbed > in OpenWrt. What was known previously as libiconv is now renamed to > libiconv-full and gettext is renamed to gettext-full. > > I can understand why it has been done. OpenWrt is tending towards ultimate > optimizations - and it includes ripping off, stubbing and whatever else > techniques to gain (sometimes questionable) speed/size improvement. > > However, Ben NanoNote is not a router. I prefer thinking about Ben as a > desktop (kind of limited, though). > > In recent months, Ben has added support for UTF-8 and i18n I/O in console > applications. OpenWrt had no such features, starting from uclibc and busybox > and ending with ncurses. > > Now when libiconv and gettext are stubbed, a lot of packages depending on > libiconv and libintl might start having problems. They won't get built or > won't have features supported by that libraries. > > OpenWrt developers realized that such stub would cause many problems and > began to "unstub" it by adding some features and now they call libiconv > "Tiny drop-in replacement for the GNU Character set conversion library". > > It is supposed that those who want full versions of libiconv and gettext > will use libiconv-full and gettext-full packages. > Well, it is possible to do this for individual packages in openwrt-packages > git, but what about all other packages depending on libiconv or libintl from > openwrt feeds? > > I'd like to know if there is a way to get the full versions back? Overriding > these libs from openwrt-packages doesn't work because libiconv and gettext > are in feeds themselves and not in base system. > > _______________________________________________ > Qi Hardware Discussion List > Mail to list (members only): [email protected] > Subscribe or Unsubscribe: > http://lists.en.qi-hardware.com/mailman/listinfo/discussion -- This email address is used for mailinglist purposes only. Non-mailinglist emails will be dropped automatically. If you want to get in contact with me personally, please mail to: mirko.vogt <at> nanl <dot> de _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
