4 ms·

Well mostly because some of us are just devs and we don t know about it ? How about a blog writeup, I'd read it :)

by zilian 8y ago

user5994461 8y ago
I don't think I ever came across a developer who made a RPM/DEB package. I'm not sure I came across a devops/sysadmin who made a RPM/DEB package in recent years. I wouldn't waste my time learning that if I were you. Software like python needs pip to build, they can't be built with the OS package manager alone.
- Spivak 8y ago
  > Software like python needs pip to build, they can't be built with the OS package manager alone. Well yeah, OS packaging formats are for putting together your build artifacts. You can use whatever to build the software. If you want to do it 'right' you would use pip to build packages for any missing runtime dependencies from your OS repos and the package your application. I swear it's much easier than it sounds. But nothing says you have do it like an OS maintainer though. You can also just vendor all your dependencies, slurp them all up in an RPM and install in /opt.
  - fatherlinnux 8y ago
    +1. Back in the day, we used to mirror all of CPAN, because even as a young buck, I saw the gap in rebuilding apps without the source copied...
- snidane 8y ago
  Well my team does that for one. We use Python packaging ecosystem, specify Python dependencies using standard tools like setup.py, requirements.txt and pip. All Python dependencies are baked into a fat Python package using PEX format[1]. Also tried Facebook's xar format[2], without success yet. What matters is to have a statically linked dependencies packaged in one executable file. Like a Windows exe file. Then you proceed with bundling in higher level OS dependencies, because each app is not just a Python package but also a collection of shell scripts, configs, configuration of paths for caches, output directories, system variables, etc. For this we throw everything into one directory tree and run FPM [3] command on it which turns the directory tree into a RPM package. We use a fpm parameter to specify installation location of that tree to /opt or /usr elsewhere. The way to bundle it properly is to actually use two rpm packages linked together by rpm dependency. One for the app and the other for the deployment configuration. The reason is you only have one executable, but many possible versions of deploying it. Ie. depending on environment (dev, staging, prod) or you just simply want to run the same app in parallel with different configuration. eg. one rpm package for the app executable and statix files my_app_exe-2.0-1.noarch.rpm and many othe related config rpms my_app_dev-1.2-1.noarch.rpm (depends on my_app_exe > 2.0) my_app_prod-3.0-1.noarch.rpm (depends on my_app_exe == 2.0) You then install only the deployment packages and rpm system fetches the dependencies for you automatically. There are other mature places who use similar techniques for deployments, for example [4]. All of this then can be wrapped in even higher level of packaging, namely Docker. [1] https://github.com/pantsbuild/pex https://github.com/pantsbuild/pex [2] https://code.fb.com/data-infrastructure/xars-a-more-efficient-open-source-system-for-self-contained-executables/ https://code.fb.com/data-infrastructure/xars-a-more-efficien... [3] https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm [4] https://hynek.me/articles/python-app-deployment-with-native-packages/ https://hynek.me/articles/python-app-deployment-with-native-...
- crehn 8y ago
  Our team still uses debs. In fact I made a tool to greatly simplify the process: https://github.com/hoffa/debpack https://github.com/hoffa/debpack
- ex_amazon_sde 8y ago
  Everything in Amazon is packaged and deployed without containers since decades. All engineers have to learn how to package their stuff.

Well mostly because some of us are just devs and we don t know about it ? How about a blog writeup, I'd read it :)

by zilian 8y ago

Well mostly because some of us are just devs and we don t know about it ? How about a blog writeup, I'd read it :)

I don't think I ever came across a developer who made a RPM/DEB package. I'm not sure I came across a devops/sysadmin who made a RPM/DEB package in recent years. I wouldn't waste my time learning that if I were you. Software like python needs pip to build, they can't be built with the OS package manager alone.

Spivak 8y ago
> Software like python needs pip to build, they can't be built with the OS package manager alone. Well yeah, OS packaging formats are for putting together your build artifacts. You can use whatever to build the software. If you want to do it 'right' you would use pip to build packages for any missing runtime dependencies from your OS repos and the package your application. I swear it's much easier than it sounds. But nothing says you have do it like an OS maintainer though. You can also just vendor all your dependencies, slurp them all up in an RPM and install in /opt.
- fatherlinnux 8y ago
  +1. Back in the day, we used to mirror all of CPAN, because even as a young buck, I saw the gap in rebuilding apps without the source copied...
snidane 8y ago
Well my team does that for one. We use Python packaging ecosystem, specify Python dependencies using standard tools like setup.py, requirements.txt and pip. All Python dependencies are baked into a fat Python package using PEX format[1]. Also tried Facebook's xar format[2], without success yet. What matters is to have a statically linked dependencies packaged in one executable file. Like a Windows exe file. Then you proceed with bundling in higher level OS dependencies, because each app is not just a Python package but also a collection of shell scripts, configs, configuration of paths for caches, output directories, system variables, etc. For this we throw everything into one directory tree and run FPM [3] command on it which turns the directory tree into a RPM package. We use a fpm parameter to specify installation location of that tree to /opt or /usr elsewhere. The way to bundle it properly is to actually use two rpm packages linked together by rpm dependency. One for the app and the other for the deployment configuration. The reason is you only have one executable, but many possible versions of deploying it. Ie. depending on environment (dev, staging, prod) or you just simply want to run the same app in parallel with different configuration. eg. one rpm package for the app executable and statix files my_app_exe-2.0-1.noarch.rpm and many othe related config rpms my_app_dev-1.2-1.noarch.rpm (depends on my_app_exe > 2.0) my_app_prod-3.0-1.noarch.rpm (depends on my_app_exe == 2.0) You then install only the deployment packages and rpm system fetches the dependencies for you automatically. There are other mature places who use similar techniques for deployments, for example [4]. All of this then can be wrapped in even higher level of packaging, namely Docker. [1] https://github.com/pantsbuild/pex https://github.com/pantsbuild/pex [2] https://code.fb.com/data-infrastructure/xars-a-more-efficient-open-source-system-for-self-contained-executables/ https://code.fb.com/data-infrastructure/xars-a-more-efficien... [3] https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm [4] https://hynek.me/articles/python-app-deployment-with-native-packages/ https://hynek.me/articles/python-app-deployment-with-native-...
crehn 8y ago
Our team still uses debs. In fact I made a tool to greatly simplify the process: https://github.com/hoffa/debpack https://github.com/hoffa/debpack
ex_amazon_sde 8y ago
Everything in Amazon is packaged and deployed without containers since decades. All engineers have to learn how to package their stuff.