I'm in the process of adding opie support to proftpd. The first step is to get an opie ebuild. Next is a mod_opie ebuild with a new "opie" USE variable. Finally, the proftpd ebuild will be changed to check for opie in the USE variable. If it is there then mod_otp will be built when proftpd is being built. This approach is needed because, unlike Apache, proftpd does not support DSOs. Reproducible: Always Steps to Reproduce:
Created attachment 12268 [details] app-crypt/opie/opie-2.4.ebuild
Created attachment 12269 [details] app-crypt/opie/ChangeLog
Created attachment 12270 [details, diff] app-crypt/opie/files/opie-2.4-gentoo.diff
Created attachment 12271 [details] license/NRL
Created attachment 12272 [details] license/INNER_NET_V2
Created attachment 12316 [details] Updated app-crypt/opie/opie-2.4.ebuild Updated opie-2.4.ebuild. Installs libopie.a and opie.h too.
Created attachment 12317 [details] Actually updated app-crypt/opie/opie-2.4.ebuild. Actually updated opie-2.4.ebuild. Forgot to cvs up before submitting changed ebuild.
This ebuild creates problems for dev-libs/cyrus-sasl. It installs libopie.a in /usr/lib. Cyrus-sasl uses it and, at least on the Alpha architecture, causes linking errors due to "gp-relative relocation against dynamic symbol xxx" (see http://skarpsey.dyndns.org/alpha-lfs/alpha.html). The solution is to generate a libopie.so. I toyed around with doing so via automake and libtool but it is giving me trouble, mostly due to the fact that I've never used automake before.
lets see what we can do about getting this supported.
Like Bug #21515, I'm not using opie in Gentoo anymore so I don't have a vested interest in seeing this ebuild accepted.
closing
