On Mo, 2014-11-24 at 00:48 +0100, Roland Smith wrote: > On Sun, Nov 23, 2014 at 12:32:14AM +0100, Christopher J. Ruwe wrote: > > I am well aware that very probably I might be starting a rant thread, > > however, I am genuinely interested in opinions from the community. > > > > Since version 24, Emacs, the very good operating system missing only a > > decent editor, has developed a package manager for Emacs > > extensions. Some good repos exist, packages are usually installed to > > ~/.emacs.d and I have come to really enjoy that way of installing > > packages. > > > > In that light and as the ports maintainer of math/ess, the Emacs > > speaks statistics R-mode of emacs, I am asking myself specifically > > whether I add any real benefit in maintaining math/ess. More > > generally, I am interested in community answers as to whether it is > > really useful to maintain Emacs-extension-packages in ports. > > > > Thanks for your thoughts, cheers, > > It might help to see this question in a broader context. > > There are several communities that have there own repositories/package > managers these days, e.g: > > * TeX > * Perl > * Python > * Ruby > * Node > * Emacs > > Yet the maintainers of the ports system go through the effort of maintaining > ports for a lot of these packages, even though it might strictly speaking be > considered a duplication of effort. > > There are at least two big reasons that I can think of; > > 1) FreeBSD specific patches are necessary to build a package. (I.e. every port > that has a files subdirectory.) The ports tree is arguably the right place > for that. The best case would be that such changes are merged upstream, but > that doesn't always happen. > 2) A foreign package might depend on a FreeBSD port or the other way > around. How could this be handled properly if not in the ports tree? > So by its very nature, if you want to reap the benefits of the ports > infrastructure for your package, you have to *use* said infrastructure. > > Packages that *can* install in a user's $HOME directory and have no > non-obvious dependencies are the exception to this rule, I think. No one will > expect e.g. a vim bundle to do anything useful when vim is not installed! > > But such packages are obviously only available to the user that has installed > them. So for a multi-user installation a port would still make more sense. > > > Roland
I think of Emacs modes differently than of Perl/Python/Ruby/Nodejs ... programs. The latter do not extend the languages, but use the language to provide independent utility to some user. Emacs modes, alike to the vim bundles you mentioned, extend Emacs (up to the ultimate goal that the user is for the whole duration of the session not forced to leave Emacs ;-) ). I cannot think of any Emacs mode being required by something non-Emacs. I have mentioned in a different answer that I see them alike to Firefox plugins. The only patches I noted so far to Emacs ports concern the placement of files, although I may well be wrong here. I have problems imaging a multi-user installation with multiple instances of Emacs mode packages installed. My elders have told tales of lore of mighty heroes connecting to machines using tools of magic called "terminals", so they all could toil on the same computer. Jokes aside, I can only think of thin client settings where one would want to avoid multiple packages of the same program installed. Isn't everybody using independent so called "personal computers" now? Without any irony, that's a real question: I thought thin client computing has more or less died, am I wrong here? Anyhow, thanks for your thoughts on that matter -- Christopher
signature.asc
Description: This is a digitally signed message part
