Portage is lagging a bit so I bumped the version locally. Only change was that the home page is now http://ess.r-project.org/ (and consequantly the SRC_URI is altered). Have attached a revised version. Reproducible: Always
Created attachment 170899 [details] Updated ebuild
Sorry about the typo in the title, this really is meant to be bumped to 5.3.8 (since 5.3.9 is basically the SVN version). Further it might be worthwhile to have the ebuild pull in the two ancillary files 'r-utils.el' and 'r-utils.elc' listed at http://ess.r-project.org/downloads/ Will have a go at adding this in myself when I've time and will update the ebuild if I get it working.
Bumped to 5.3.8, thanks. (In reply to comment #2) > Further it might be worthwhile to have the ebuild pull in the two ancillary > files 'r-utils.el' and 'r-utils.elc' listed at > http://ess.r-project.org/downloads/ Upstream states "not part of ESS" and doesn't bundle it with their tarball. Probably it should go into a separate package? Would also be easier to maintain.
(In reply to comment #3) > (In reply to comment #2) > > Further it might be worthwhile to have the ebuild pull in the two ancillary > > files 'r-utils.el' and 'r-utils.elc' listed at > > http://ess.r-project.org/downloads/ > > Upstream states "not part of ESS" and doesn't bundle it with their tarball. > Probably it should go into a separate package? Would also be easier to > maintain. > Cheers for bumping portage. It may not be an official part of the tarball, but then patches that are applied to packages aren't either? Given that there would be an exceptionally tight dependency on ess should they be placed in a separate package is there any advantage to having the lisp files in a separate package? The files are dated 2004 and don't appear to have changed much (although obviously that doesn't preclude them changing in the future), so there may not be much maintenance anyway?
> It may not be an official part of the tarball, but then patches that are > applied to packages aren't either? Yes, but it also is our explicit policy to submit such patches upstream (see <http://www.gentoo.org/main/en/contract.xml>). But in this case we know in advance that upstream wouldn't accept it. > Given that there would be an exceptionally tight dependency on ess should > they be placed in a separate package is there any advantage to having the > lisp files in a separate package? Is there any disadvantage? ;-) But seriously, it's a borderline case. Also, r-utils.el would need app-emacs/emacs-w3m as an additional dependency. Anyway, I think that you should open a new enhancement bug for r-utils (independent from its being a separate package or not). This bug is resolved.
(In reply to comment #5) OK, cool, not a problem. Cheers Neil
