Re: [Fwd: [PATCH] packages: Define encode-mime-charset-string as function]

apel-en removed because it just bounces for non-members. Ville> Ouch. A grep into the package source tree reveals that Ville> mule-base, bbdb, liece, rmail and tm require apel... maybe Ville> they should be "fixed"? rmail and tm are obsolete; rmail is actively maintained at GNU, but I don't think anybody here uses it at all. tm is needed for rmail, I think, and ancient Gnus, and mh-e, and that's about it. I don't know how hard removing an APEL dependency from any of those packages would be. For mule-base, we might just want to move it into core anyway. The other two are externally maintained, so would require negotiation to "fix". For BBDB at least if we were to remove that dependency by synching to GNU I bet they'd jump for joy ;-) Ville> Okay. But I wasn't suggesting that the package would be Ville> byte-compiled at all before it's loaded, neither in the Ville> released package or locally after installation. Wouldn't Ville> the .el files be enough, provided that the package system Ville> would really enforce the requirements (fsf-compat, Ville> xemacs-base)? This is one problem; the package system does _not_ enforce such requirements. This also is a real performance hit. Ville> People wanting to byte-compile apel would be on their Ville> own. OTOH, as you noted, I guess this probably wouldn't Ville> make our support task easier. No, and it's really against the philosphy of the packages. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py