Excerpts from Peter FELECAN's message of Thu Jul 16 14:34:23 -0400 2009: > It's strictly true for Emacs and that is the reference package. All the > others are just optional components for which an Emacs savvy user doesn't > have issues installing for himself or site wide. Of course, a savvy > packager do better for his users.
Ok. I think we've both been clear on our preferences. You have your reasons and I'm ok with them. > As stated in my previous message I'm not opposed to it but wished to > know the rational. As I'm not satisfied with that I'll continue to > supply the .elc in my packages and separately the .el Ok. I'm interested in standardizing something for this though. It would be better for the users if all of our emacs packaged bits presented a similar experience. Shall we agree then that any package providing emacs add-on modules/functionality should provide .elc files in the primary package and offer an _el version of the package to deliver the .el source files? That's what you've said, but should this become the formal policy? A side thought: Does it make sense to have this policy be different than the python policy? In theory, python add-ons could ship only the .pyc/.pyo files and provide _py packages for the .py source...I'm wondering this aloud for my own curiosity more than anything. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting.
signature.asc
Description: PGP signature
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers
