I have wondered whether we should sort of deprecated it more officially, since otherwise I think people have the reasonable expectation based on the current code that Spark intends to support "complete" Debian packaging as part of the upstream build. Having something that's sort-of maintained but no one is helping review and merge patches on it or make it fully functional, IMO that doesn't benefit us or our users. There are a bunch of other projects that are specifically devoted to packaging, so it seems like there is a clear separation of concerns here.
On Mon, Feb 9, 2015 at 7:31 AM, Mark Hamstra <m...@clearstorydata.com> wrote: >> >> it sounds like nobody intends these to be used to actually deploy Spark > > > I wouldn't go quite that far. What we have now can serve as useful input > to a deployment tool like Chef, but the user is then going to need to add > some customization or configuration within the context of that tooling to > get Spark installed just the way they want. So it is not so much that the > current Debian packaging can't be used as that it has never really been > intended to be a completely finished product that a newcomer could, for > example, use to install Spark completely and quickly to Ubuntu and have a > fully-functional environment in which they could then run all of the > examples, tutorials, etc. > > Getting to that level of packaging (and maintenance) is something that I'm > not sure we want to do since that is a better fit with Bigtop and the > efforts of Cloudera, Horton Works, MapR, etc. to distribute Spark. > > On Mon, Feb 9, 2015 at 2:41 AM, Sean Owen <so...@cloudera.com> wrote: > >> This is a straw poll to assess whether there is support to keep and >> fix, or remove, the Debian packaging-related config in Spark. >> >> I see several oldish outstanding JIRAs relating to problems in the >> packaging: >> >> https://issues.apache.org/jira/browse/SPARK-1799 >> https://issues.apache.org/jira/browse/SPARK-2614 >> https://issues.apache.org/jira/browse/SPARK-3624 >> https://issues.apache.org/jira/browse/SPARK-4436 >> (and a similar idea about making RPMs) >> https://issues.apache.org/jira/browse/SPARK-665 >> >> The original motivation seems related to Chef: >> >> >> https://issues.apache.org/jira/browse/SPARK-2614?focusedCommentId=14070908&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14070908 >> >> Mark's recent comments cast some doubt on whether it is essential: >> >> https://github.com/apache/spark/pull/4277#issuecomment-72114226 >> >> and in recent conversations I didn't hear dissent to the idea of removing >> this. >> >> Is this still useful enough to fix up? All else equal I'd like to >> start to walk back some of the complexity of the build, but I don't >> know how all-else-equal it is. Certainly, it sounds like nobody >> intends these to be used to actually deploy Spark. >> >> I don't doubt it's useful to someone, but can they maintain the >> packaging logic elsewhere? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org >> For additional commands, e-mail: dev-h...@spark.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
