I think option 2 is a really good way forward for the project. If the project could provide packages for the tested platforms it will reduce the amount of work required to setup Mesos.
On Tue, Sep 22, 2015 at 6:04 AM, Jake Farrell <jfarr...@apache.org> wrote: > Not an easy project decision for sure, #2 adds some more work for the > project and #1 can leave a bad impression of the project when a 3rd party > does not keep its implementation current or maintained. Personally I tend > to favor #2 as it keeps everything with the project and makes it easier for > the end user. > > As for the CI, it can not produce official binary distributions as those > require a vote. You can run the packaging as part of your testing, process > but these resulting artifacts must be marked as snapshots and can not be > uploaded for distribution. > > For official rpm/deb packages infra leverages bintray to do the actual > hosting of the packages. I am currently working on scripting the process > for publishing the package artifacts for Aurora to bintray. I also have > native deb packaging for Mesos in my github fork available at [1]. If > either of these are something that are of interest I'm happy to contribute > them back to Mesos as patches and help maintain them moving forward. > > -Jake > > [1]: https://github.com/jfarrell/mesos/tree/debian-packaging > > > > > > On Mon, Sep 21, 2015 at 4:01 PM, Vinod Kone <vinodk...@apache.org> wrote: > >> +Jake Farrell >> >> The mesos project doesn't publish platform dependent artifacts. We >> currently only publish platform independent artifacts like JAR (to apache >> maven) and interface EGG (to PyPI). >> >> Recently we made the decision >> <http://www.mail-archive.com/dev%40mesos.apache.org/msg33148.html> for >> the project to not officially support different language (java, python) >> framework libraries going forward (likely after 1.0). The project will only >> support C++ libraries which will live in the repo and link to other >> language libraries from our website. >> >> The main reason was that the PMC lacks the expertise to support various >> language bindings and hence we wanted to remove the support burden. >> >> Option #1) It looks like we could do a similar thing with RPMs/DEBs, >> i.e., link to 3rd party artifacts from the project website. Similar to the >> client library authors, we could hold package maintainers accountable by >> providing guidelines. >> >> Option #2) Since the project officially supports certain platforms >> (Ubuntu, CentOS, OSX) and continuously tests this via CI, we could've the >> CI continuously build and upload the packages. Not sure what's ASF stance >> on this is. I filed a ticket >> <https://issues.apache.org/jira/browse/INFRA-10385> a while ago with >> INFRA regarding something similar, but never received any response. >> >> Personally, with the direction the project is headed towards, I prefer #1. >> >> On Sat, Sep 19, 2015 at 3:39 AM, Carlos Sanchez <car...@apache.org> >> wrote: >> >>> I'm using the same repo with some changes to build SSL enabled packages >>> >>> >>> https://github.com/carlossg/mesos-deb-packaging/compare/master...carlossg:ssl >>> >>> >>> On Sat, Sep 19, 2015 at 4:22 AM, Rad Gruchalski <ra...@gruchalski.com> >>> wrote: >>> > Should be rather easy to package it with this little tool from >>> Mesosphere: >>> > https://github.com/mesosphere/mesos-deb-packaging. I’ve done it >>> myself for >>> > ubuntu 12.04 and 14.04. >>> > The only thing that needs to be changed are the dependencies, for >>> ubuntu >>> > this was: >>> > >>> > diff --git a/build_mesos b/build_mesos >>> > index 81561bc..f756ef0 100755 >>> > --- a/build_mesos >>> > +++ b/build_mesos >>> > @@ -313,9 +313,10 @@ function deb_ { >>> > --deb-recommends zookeeperd >>> > --deb-recommends zookeeper-bin >>> > -d 'java-runtime-headless' >>> > - -d libcurl3 >>> > - -d libsvn1 >>> > - -d libsasl2-modules >>> > + -d libcurl4-nss-dev >>> > + -d libsasl2-dev >>> > + -d libapr1-dev >>> > + -d libsvn-dev >>> > >>> > It does look like the tool can build RPMs. >>> > >>> > Kind regards, >>> > Radek Gruchalski >>> > ra...@gruchalski.com >>> > de.linkedin.com/in/radgruchalski/ >>> > >>> > Confidentiality: >>> > This communication is intended for the above-named person and may be >>> > confidential and/or legally privileged. >>> > If it has come to you in error you must take no action based on it, >>> nor must >>> > you copy or show it to anyone; please delete/destroy and inform the >>> sender >>> > immediately. >>> > >>> > On Saturday, 19 September 2015 at 04:09, craig w wrote: >>> > >>> > Mesosphere provides packages, you can find more information here: >>> > https://mesosphere.com/downloads/ >>> > >>> > As of right now, they don't seem to have a 0.24.0 package. >>> > >>> > On Fri, Sep 18, 2015 at 8:51 PM, Brian Hicks <br...@brianthicks.com> >>> wrote: >>> > >>> > We've got some experimental packages at bintray.com/asteris/mantl-rpm, >>> > source is at github.com/asteris-llc/mesos-packaging. They can really >>> use >>> > some testing if you wanted to give them a try. Configuration is a bit >>> > different than the Mesosphere packages, see the repo for details. >>> > >>> > On Sep 18, 2015 7:01 PM, "Zameer Manji" <zma...@apache.org> wrote: >>> > >>> > Hey, >>> > >>> > Does the Apache Mesos project provide OS packages for installation? I >>> > haven't been able to find any for the 0.24 release and I think having >>> them >>> > would make installing Mesos a lot easier. >>> > >>> > -- >>> > Zameer Manji >>> > >>> > >>> > >>> > >>> > -- >>> > >>> > https://github.com/mindscratch >>> > https://www.google.com/+CraigWickesser >>> > https://twitter.com/mind_scratch >>> > https://twitter.com/craig_links >>> > >>> > >>> >>> -- >>> Zameer Manji >>> >>>
