I've created an ebuild for app-emacs/pov-mode-3.2 which I'd like to propose for inclusion. I'm willing to commit it to sunrise, but after waiting over an hour on #gentoo-sunrise without so much as a comment, I'm not shure when that's going to happen. So I'll attach files here first.
Created attachment 278807 [details] app-emacs/pov-mode/pov-mode-3.2.ebuild
Created attachment 278809 [details] app-emacs/pov-mode/files/50pov-mode-gentoo.el
We can add the package to the Emacs overlay, or to the main tree directly. Some minor points: - insinto is relative to ${ED}, so ${EPREFIX} doesn't belong there - FDL-1.2 should be added to LICENSE (for the texinfo stuff) - defvar in a site-init file is almost always wrong, use setq instead I'll also have a look at elisp.eclass if texinfo/info handling can be improved. I'd rather avoid moving files around in the ebuild.
(In reply to comment #3) > We can add the package to the Emacs overlay, or to the main tree directly. That'd be great! > Some minor points: > - insinto is relative to ${ED}, so ${EPREFIX} doesn't belong there It is??? As the ebuild(5) wasn't specific on this point, I had a look at the source of that function: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blame;f=bin/ebuild.sh;hb=d9fc4acc572c6647a4f27b838d35d27d805d190e#l662 There the function creates the directory "${D}${INSDESTTREE}", where INSDESTTREE is simply the $1 argument to the insinto call, in this case. The doins script doesn't introduce special EPREFIX handling either: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=bin/ebuild-helpers/doins;h=7dec146825b8991a8a2e4683ed83b9257faa578e;hb=HEAD#l76 So unless I read something terribly wrong, I believe you are mistaken. > - FDL-1.2 should be added to LICENSE (for the texinfo stuff) Oh, makes sense. Will correct that once we agree on the previous point. > - defvar in a site-init file is almost always wrong, use setq instead Why so? I think that defcvar is cleaner, as it tells Emacs that the symbol in question is in fact intended as a global variable. Not sure whether it would emit a warning otherwise, but I feel using defvar this way is very much in its spirit. As we load the actual pov-mode code lazily, the defvar contained there will not have executed by the time we execute our own. So we would have a setq before the corresponding defvar. I guess one major reason for using defvar instead of setq is that defvar does a weak assignment: if the symbol is defined already, it will not be overwritten. I consider this a good thing, as pov-mode declares that symbol as configurable. So users might customize the directory (although I see no reason why they should), and would probably expect their customization to have an effect. Customizations are usually assigned at the beginning of init.el (or similar), whereas loading of specific init files might come after that. In such a setup, an unconditional setq would in my understanding override the customization. It has always be my philosophy that a program shouldn't try being more clever than its user, so if the user wants to customize something, please accept that. > I'll also have a look at elisp.eclass if texinfo/info handling can be > improved. I'd rather avoid moving files around in the ebuild. This is untested, but probably something along these lines will work: set -- ${ELISP_TEXINFO} +set -- ${@##*/} doinfo ${@/%.*/.info*} || die As an alternative, you could adjust the makeinfo call to write to a specific file, but in this case you'd have to process each input file separately.
By the way, I've had contact with Marco Pessotto, the upstream maintainer. There is a more public SRC_URI for the tarball: http://tromey.com/elpa/pov-mode-3.2.tar Will use that in my next iteration of the ebuild. There also is a public git reporitory: https://gitorious.org/pov-mode/pov-mode/trees/master So far the only difference from the tarball is a change in maintainer e-mail address, so you want to keep this in mind when contacting upstream. Do you want a comment in the ebuild, to note these facts for future reference?
(In reply to comment #4) > > - insinto is relative to ${ED}, so ${EPREFIX} doesn't belong there > It is??? As the ebuild(5) wasn't specific on this point, I had a look at the > source of that function: > [...] > So unless I read something terribly wrong, I believe you are mistaken. You're looking at the wrong branch. There's no prefix support in standard portage (yet). In the prefix branch, the function uses ED: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=bin/ebuild.sh;h=a0b7b154e0f1d6fdac786685ee274687b872b5f9;hb=prefix#l842> > > - defvar in a site-init file is almost always wrong, use setq instead > Why so? I think that defcvar is cleaner, as it tells Emacs that the symbol > in question is in fact intended as a global variable. Not sure whether it > would emit a warning otherwise, but I feel using defvar this way is very > much in its spirit. [...] It would also have the effect that C-h v (i.e. describe-variable) would point to site-gentoo.el instead of pov-mode.el. IMHO there should be only one defvar for a variable, and it should _not_ be in our site init files. > Customizations are usually assigned at the beginning of init.el (or > similar), whereas loading of specific init files might come after that. In > such a setup, an unconditional setq would in my understanding override the > customization. It has always be my philosophy that a program shouldn't try > being more clever than its user, so if the user wants to customize > something, please accept that. User customizations are saved in their ~/.emacs file (this is the default behaviour at least) which is executed after site-start.el. So unless I'm completely mistaken, any assignments done in site-gentoo.el will be overridden by the user customization. (I've already thought about introducing a Gentoo customization theme for all custom variables that we set in our init files, i.e. we would set them with custom-theme-set-variables. However, this will have to wait until we finally drop support for Emacs 21.) (In reply to comment #5) > There is a more public SRC_URI for the tarball: > http://tromey.com/elpa/pov-mode-3.2.tar It's uncompressed though. :( > There also is a public git reporitory: > https://gitorious.org/pov-mode/pov-mode/trees/master This might make a better HOMEPAGE than that unrelated Lee Xah site. > So far the only difference from the tarball is a change in maintainer e-mail > address, so you want to keep this in mind when contacting upstream. Do you > want a comment in the ebuild, to note these facts for future reference? Better not. E-mail addresses tend to change, and chances are that the one in the ebuild would at some point become outdated too.
(In reply to comment #6) > You're looking at the wrong branch. Thanks for pointing this out! > User customizations are saved in their ~/.emacs file (this is the default > behaviour at least) which is executed after site-start.el. So unless I'm > completely mistaken, any assignments done in site-gentoo.el will be overridden > by the user customization. If you load site-gentoo from site-start. I've got a setup where I don't force packages on all users, and instead allow users to load the individual startup files from their ~/.emacs.d/init.el, either using a positive or a negative selection list. May be a non-standard aproach, but I like it very much. But I see your point for the single defvar, and will try out a setq. Shouldn't cause trouble for me either, I think. > (I've already thought about introducing a Gentoo customization theme for all > custom variables that we set in our init files, i.e. we would set them with > custom-theme-set-variables. However, this will have to wait until we finally > drop support for Emacs 21.) Don't understand what you mean by "theme". > > There is a more public SRC_URI for the tarball: > > http://tromey.com/elpa/pov-mode-3.2.tar > > It's uncompressed though. :( Yes, that's true. I won't mind using my own copy either, but I can't promise to keep it updated if new versions arrive. > > There also is a public git reporitory: > > https://gitorious.org/pov-mode/pov-mode/trees/master > > This might make a better HOMEPAGE than that unrelated Lee Xah site. For maintainers, you are probably right. For users, http://xahlee.org/3d/povray_emacs.html has more information about how to use the mode. > > So far the only difference from the tarball is a change in maintainer e-mail > > address, so you want to keep this in mind when contacting upstream. Do you > > want a comment in the ebuild, to note these facts for future reference? > > Better not. E-mail addresses tend to change, and chances are that the one in > the ebuild would at some point become outdated too. I wouldn't want to include the address itself, but only the reference to gitorious (homepage would be all right for that) and a note that the README there contains an email address which is more up to date than the one in the tarball.
Created attachment 279789 [details] app-emacs/pov-mode/pov-mode-3.2.ebuild Updated ebuild. + Uses gitorious as homepage + A comment mentions the updated email contact there + Uncompressed elpa source tarball mentioned in a comment + Includes the FDL license + Drops the duplicate EPREFIX reference + Will also install InsertMenu templates shipped with the mode - Still does the moving-around for texinfo files
Created attachment 279791 [details] app-emacs/pov-mode/files/50pov-mode-gentoo.el Updated site-init file. + Use setq instead of defvar to customize locations + Customize some more directories, including that for InstallMenu - directories in /usr/share hardcoded, won't work with non-empty EPREFIX (you might want to add a suitable substitution to elisp-site-file-install) - pov documentation directory requires DOC_SYMLINKS_DIR="/usr/share/doc/html" in /etc/make.conf. Couldn't think of a cleaner solution. Keyword lookup doesn't seem to work in any case.
Added to Emacs overlay, with some cosmetic changes to the ebuild. I've also committed an updated elisp.eclass to the overlay. Let's wait for the usual testing period of one month, then both eclass and package can be moved to the Portage tree. Concerning the site-init file: - I've commented out the assignment of pov-documentation-directory. We cannot rely on any settings in make.conf. - The .inc suffix is used for various types of files (e.g., Fortran) and I think that adding it to auto-mode-alist would be asking for trouble. Therefore, this is commented out, too.
Updated eclass and package committed to Portage tree. Thank you for the contribution.
