Re: How does Mesos Debian packaging work?
Some dependencies ended up in the script historically, others are added incrementally (like libsvn1 is required since 0.21). libunwind* could be removed, the libcurl-dev dependency can't be removed. You can easily check this with ldd: $ ldd /usr/lib/libmesos-0.22.1.so ... libapr-1.so.0 = /usr/lib/libapr-1.so.0 (0x7f35be6b6000) libcurl-nss.so.4 = /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4 (0x7f35be44f000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f35be238000) ... In this case the package was built with libcurl4-nss-dev installed, and therefore libmesos.so requires libcurl-nss.so.4 Another dependency that is missing, is for example python 2.7 which is somehow expected to be present on your system if you wanna use Mesos CLI tools. This should be moved to a separate package, so that you don't have to install python and java when you need just libmesos.so. I've started working on a proper Debian packaging a while ago, however I didn't have time to finish that. If you're interested in, any help would be appreciated. On 5 August 2015 at 02:11, Jay Taylor j...@jaytaylor.com wrote: I see, thank you Tomas for that updated mesos-deb-packaging link. Helpful information to be sure. I'm am still curious about why mesosphere-hosted deb's end up with less dependencies than the builds done by the mesos-deb-packaging scripts. Is there really no way to generate a roughly equivalent build? The hopeful dream I have is to be able to build (then distribute and install across my cluster) a `.deb` containing my own modifications. Then if/when it explodes to be able to just revert back to the official releases; __ideally not having to install extra libraries along the way, change configurations, or inflict other [unnecessary] system mutations__. Is this asking too much of mesos/mesosphere in their present forms? On Tue, Aug 4, 2015 at 4:42 PM, Tomas Barton barton.to...@gmail.com wrote: Hi Jay, as long as the libcurl-dev dependency is concerned you can use any of libcurl4-openssl-dev, libcurl4-gnutls-dev or libcurl4-nss-dev. Just make sure one of these libraries is installed on all of your worker (slave) nodes. If you don't need any modification of the mesos packaging, you can use pre-built packages from Mesosphere: http://open.mesosphere.com/downloads/mesos If you need some modification, you should fork https://github.com/mesosphere/mesos-deb-packaging which is far more maintained. Anyway none of these packaging is close to an ideal solution. A proper Debian package would distinguish between a mesos-master, mesos-slave, libmesos, java and python binding etc. Regards, Tomas On 4 August 2015 at 22:36, Jay Taylor outtat...@gmail.com wrote: Greetings Mesonians, What is the procedure for creating debian/ubuntu .deb distribution builds of Mesos? I am currently using https://github.com/deric/mesos-deb-packaging, but it seems to add some dependencies (libunwind* and libcurl4-nss-dev) that the mesosphere-hosted distributions do not, and I strongly prefer creating artifacts comparable to what is emitted in the official builds. Thanks, Jay
Re: How does Mesos Debian packaging work?
The Mesosphere packages use mesos-deb-packaging to build them, currently at commit 4897858c4d93d3c6be1cad23bdea40c13d60e3bc. The only additional piece that is added is some wrapper scripts to spin up AWS machines, install the necessary dependencies, then run the build in those VMs, then do a basic install / test of the packages. On Wed, Aug 5, 2015 at 1:04 AM Tomas Barton barton.to...@gmail.com wrote: Some dependencies ended up in the script historically, others are added incrementally (like libsvn1 is required since 0.21). libunwind* could be removed, the libcurl-dev dependency can't be removed. You can easily check this with ldd: $ ldd /usr/lib/libmesos-0.22.1.so ... libapr-1.so.0 = /usr/lib/libapr-1.so.0 (0x7f35be6b6000) libcurl-nss.so.4 = /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4 (0x7f35be44f000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f35be238000) ... In this case the package was built with libcurl4-nss-dev installed, and therefore libmesos.so requires libcurl-nss.so.4 Another dependency that is missing, is for example python 2.7 which is somehow expected to be present on your system if you wanna use Mesos CLI tools. This should be moved to a separate package, so that you don't have to install python and java when you need just libmesos.so. I've started working on a proper Debian packaging a while ago, however I didn't have time to finish that. If you're interested in, any help would be appreciated. On 5 August 2015 at 02:11, Jay Taylor j...@jaytaylor.com wrote: I see, thank you Tomas for that updated mesos-deb-packaging link. Helpful information to be sure. I'm am still curious about why mesosphere-hosted deb's end up with less dependencies than the builds done by the mesos-deb-packaging scripts. Is there really no way to generate a roughly equivalent build? The hopeful dream I have is to be able to build (then distribute and install across my cluster) a `.deb` containing my own modifications. Then if/when it explodes to be able to just revert back to the official releases; __ideally not having to install extra libraries along the way, change configurations, or inflict other [unnecessary] system mutations__. Is this asking too much of mesos/mesosphere in their present forms? On Tue, Aug 4, 2015 at 4:42 PM, Tomas Barton barton.to...@gmail.com wrote: Hi Jay, as long as the libcurl-dev dependency is concerned you can use any of libcurl4-openssl-dev, libcurl4-gnutls-dev or libcurl4-nss-dev. Just make sure one of these libraries is installed on all of your worker (slave) nodes. If you don't need any modification of the mesos packaging, you can use pre-built packages from Mesosphere: http://open.mesosphere.com/downloads/mesos If you need some modification, you should fork https://github.com/mesosphere/mesos-deb-packaging which is far more maintained. Anyway none of these packaging is close to an ideal solution. A proper Debian package would distinguish between a mesos-master, mesos-slave, libmesos, java and python binding etc. Regards, Tomas On 4 August 2015 at 22:36, Jay Taylor outtat...@gmail.com wrote: Greetings Mesonians, What is the procedure for creating debian/ubuntu .deb distribution builds of Mesos? I am currently using https://github.com/deric/mesos-deb-packaging, but it seems to add some dependencies (libunwind* and libcurl4-nss-dev) that the mesosphere-hosted distributions do not, and I strongly prefer creating artifacts comparable to what is emitted in the official builds. Thanks, Jay
Re: How does Mesos Debian packaging work?
I see, thank you Tomas for that updated mesos-deb-packaging link. Helpful information to be sure. I'm am still curious about why mesosphere-hosted deb's end up with less dependencies than the builds done by the mesos-deb-packaging scripts. Is there really no way to generate a roughly equivalent build? The hopeful dream I have is to be able to build (then distribute and install across my cluster) a `.deb` containing my own modifications. Then if/when it explodes to be able to just revert back to the official releases; __ideally not having to install extra libraries along the way, change configurations, or inflict other [unnecessary] system mutations__. Is this asking too much of mesos/mesosphere in their present forms? On Tue, Aug 4, 2015 at 4:42 PM, Tomas Barton barton.to...@gmail.com wrote: Hi Jay, as long as the libcurl-dev dependency is concerned you can use any of libcurl4-openssl-dev, libcurl4-gnutls-dev or libcurl4-nss-dev. Just make sure one of these libraries is installed on all of your worker (slave) nodes. If you don't need any modification of the mesos packaging, you can use pre-built packages from Mesosphere: http://open.mesosphere.com/downloads/mesos If you need some modification, you should fork https://github.com/mesosphere/mesos-deb-packaging which is far more maintained. Anyway none of these packaging is close to an ideal solution. A proper Debian package would distinguish between a mesos-master, mesos-slave, libmesos, java and python binding etc. Regards, Tomas On 4 August 2015 at 22:36, Jay Taylor outtat...@gmail.com wrote: Greetings Mesonians, What is the procedure for creating debian/ubuntu .deb distribution builds of Mesos? I am currently using https://github.com/deric/mesos-deb-packaging, but it seems to add some dependencies (libunwind* and libcurl4-nss-dev) that the mesosphere-hosted distributions do not, and I strongly prefer creating artifacts comparable to what is emitted in the official builds. Thanks, Jay
How does Mesos Debian packaging work?
Greetings Mesonians, What is the procedure for creating debian/ubuntu .deb distribution builds of Mesos? I am currently using https://github.com/deric/mesos-deb-packaging, but it seems to add some dependencies (libunwind* and libcurl4-nss-dev) that the mesosphere-hosted distributions do not, and I strongly prefer creating artifacts comparable to what is emitted in the official builds. Thanks, Jay
Re: How does Mesos Debian packaging work?
Hi Jay, as long as the libcurl-dev dependency is concerned you can use any of libcurl4-openssl-dev, libcurl4-gnutls-dev or libcurl4-nss-dev. Just make sure one of these libraries is installed on all of your worker (slave) nodes. If you don't need any modification of the mesos packaging, you can use pre-built packages from Mesosphere: http://open.mesosphere.com/downloads/mesos If you need some modification, you should fork https://github.com/mesosphere/mesos-deb-packaging which is far more maintained. Anyway none of these packaging is close to an ideal solution. A proper Debian package would distinguish between a mesos-master, mesos-slave, libmesos, java and python binding etc. Regards, Tomas On 4 August 2015 at 22:36, Jay Taylor outtat...@gmail.com wrote: Greetings Mesonians, What is the procedure for creating debian/ubuntu .deb distribution builds of Mesos? I am currently using https://github.com/deric/mesos-deb-packaging, but it seems to add some dependencies (libunwind* and libcurl4-nss-dev) that the mesosphere-hosted distributions do not, and I strongly prefer creating artifacts comparable to what is emitted in the official builds. Thanks, Jay
