My son Byrel and I have made three programs that we want to make into packages for distributing with the XEmacs packaging system: an easy way to change buffer colors, an implementation of icon themes,

I am not finding a step by step list of directions to make some lisp code and some documentation into a package. Is there such a list, and if not, where do I go to learn how to make a package?

Also, is there an approval/review process for packages?

smitchel writes: > I can find descriptions of the package system, how to use it to update > your packages etc, but I am not finding a step by step list of > directions to make some lisp code and some documentation into a package. > Is there such a list, and if not, where do I go to learn how to make a > package? > From your description, I don't think you're referring to the node in the Lispref. Eval the following form and tell me if that helps: (Info-goto-node "(lispref)Packaging")

Note that if you're going to contribute the package to XEmacs it must build in the context of our package tree. There is no provision for standalone builds of packages just from Lisp libraries, and none for uploads of tarballs etc.

For single libraries, it's usually easiest to just add them to a related existing package.

__________ Information from ESET Smart Security, version of virus signature database 6551 (20111017) __________ The message was checked by ESET Smart Security. http://www.eset.com

smitchel writes: > > (Info-goto-node "(lispref)Packaging") > Thank you. That does help. I still have some doubt about parts of it. Good. Having doubts is expected (unfortunately, that's life! of course, it's not intended but we're all imperfect...). > > Note that if you're going to contribute the package to XEmacs it must > > build in the context of our package tree. There is no provision for > > standalone builds of packages just from Lisp libraries, and none for > > uploads of tarballs etc. > I can't see how it would be possible to make a build just from lisp > code--are you making the point that it must have documentation, a > manifest, etc in addition to lisp code? No. Of course, documentation is expected as part of general quality assurance. However, the official distribution is done by the volunteer Package Release Engineer (currently Norbert Koch, aka "viteno"), not by individual package maintainers. The generic process is: 1. you create content (code, documentation, auxiliary data such as images) 2. you commit your new and updated content to the official repository 3. Norbert builds and releases a preview package (usually within 24 hours) 4. testers comment 5. if needed, you and other developers fix bugs and addresses RFEs; goto 2 6. Norbert moves the preview to the main download archive (typically a month or two I think) 7. eventually Norbert builds and releases a new "SUMO" tarball. Administrative steps required of you (one time per developer): 1. Get a bitbucket account at bitbucket.com 2. Upload an SSH key to your bitbucket account 3. Inform mike(a)xemacs.org of your *account name* at bitbucket (eventually that will be xemacs-services(a)xemacs.org, but right now Mike is the only one with the know-how). Administrative steps required of you (one time per package): 1. Request authorization for packages you want to contribute to (this is purely a formality for most packages, especially if you contribute a brand new library, but many existing packages have "external maintainers" and we check with them first). > And, just so I am understanding right, "none for uploads of tarballs" is > referring to a tarball that contains lisp code only, or a tarball that > does not conform to how the package system wants them? No, that means "no uploads of tarballs". The only way to add content to the official XEmacs package distribution is by committing it to the repository. You are of course allowed to maintain and distribute tarballs yourself, but if you call them "XEmacs packages" then the tarball must have the following content: 1. all entry-points to Lisp code must be in libraries in lisp/$PKG/, and all Lisp code should be located under that directory 2. the auto-autoloads.el and custom-load.el files must be present 3. all libraries normally used in your package (including optional ones) should be present in both source and byte-compiled form (including auto-autoloads and custom-load); the exceptions are things like example sources that you don't support but provide as-is 4. all prebuilt Info manuals should be in info/ (not info/$PKG) 5. all scripts etc which are not Emacs Lisp should be in lib-src/ (not lib-src/$PKG); providing binary executables is allowed but not recommended -- instead you should currently negotiate to get their sources into the XEmacs core since packages don't provide a way to compile per platform 6. all other data should be in etc/$PKG/, which you can organize as you like 7. there must be a pkginfo/MANIFEST.$PKG file, which contains a list of all files (including itself!) your package installs into the tree. (Ie, uninstalling $PKG is done by "cat pkginfo/MANIFEST.$PKG | xargs rm -f".) > The info page I got to from the link above says a package is a > tarball, with restrictions on how it is made: Yes, that's true, but for the official distribution, *we* make the tarballs. Like Debian, we insist on building those from source checked into our package repository. You *can* build XEmacs packages for separate distribution yourself, but since most libraries require code from other packages, it's easiest to get consistent results by building in the XEmacs package source tree checked out from bitbucket, using the build infrastructure. __________ Information from ESET Smart Security, version of virus signature database 6552 (20111018) __________ The message was checked by ESET Smart Security. http://www.eset.com