3 ms·

I'm no expert in those earlier tools, but how does "building a deb" look if the app is in Python or NodeJS, say? With Docker I can take a base userland, instal

I'm no expert in those earlier tools, but how does "building a deb" look if the app is in Python or NodeJS, say? With Docker I can take a base userland, install pip, use pip to add libraries, then add my own files, and once I've done that and created an "image" it's just a tarfile: it will unpack everywhere and run. I can do this without any expertise in pip, rpm, yum, npm, etc., etc. Just follow a couple of recipes once, and if they work then my containers always work. That's a key attraction.

Denzel 9y ago
> [...] it will unpack everywhere and run. Hate to be pedantic: it will run on an OS that shares the same kernel or newer (assuming backwards compatibility). This type of "run anywhere" statement caused a lot of confusion for me re: Docker when I first started looking into it.
- bboreham 9y ago
  This is never a problem in practice. All the syscalls for files, sockets, etc., have stayed the same for years. [edit] backstopped by Docker requiring at least 3.10
  - Denzel 9y ago
    Sure, and what of the users' applications running in the Docker container. It's just not the type of "run anywhere" I was expecting based on the marketing/hype. And the more people kept saying "package once, run anywhere" the more I began to wonder how Docker was able to accomplish that without being a VM. Short answer: they don't. I'm not saying Docker isn't valuable. It is. I just wish it was documented more readily, without having to sift through jargon, that Docker containers must run on a compatible kernel. Essentially, I found it confusing how Docker was sold as a lightweight VM.
lathiat 9y ago
The thing is that writing a Dockerfile is basically the same thing as packaging a deb/rpm The difference is the language is more friendly to entry level usage. You still had to learn something. And they made 1 file-ish which traditionally most package managements weren't.
- bboreham 9y ago
  So in a deb I can run "pip install foo"? I have this idea that deb is more file-oriented. Never looked into it properly.
  - yebyen 9y ago
    Take a deb and run "ar -xv" on it You will get out a control.tar.gz, data.tar.gz, and debian-binary file which is a text document with a version for something in it. (Not the package version. Maybe DPKG api version.) Now, just look at how simple this structure is and marvel at how quickly you can demystify debs! If you wanted to run "pip install" you could do it in the postinst, a part of control.tar.gz, but this is not the traditional way in a deb. No reason you couldn't do it. Traditionally you should list those pip dependencies as dependencies in control and let debuild or your preferred deb building tool pack it up this way for you, then they can be frozen and will be reproducible through only the package mirrors. (The dependencies are listed as dependencies, and they are also packaged into debs.) I am looking at my heroku_3.99.4_all.deb that I happened to find first, and data.tar.gz contains a single empty directory usr/local/heroku/ for the place that postinst will dump things into (postinst does a wget to some path at https://cli-assets.heroku.com https://cli-assets.heroku.com, and moves a few things around after that.) IMHO this is a terrible deb, because if heroku goes away it will completely bomb out and fail to install. (Then again if heroku does go away, what do you need the heroku client for exactly?) Your suggestion of doing pip install has the same problem, but what's worse? I am a rubyist and I would never question whether you should use bundler to manage your dependencies. Absolutely you should, the package versions in stable distros are atrocious and usually horrifically outdated, and you almost certainly don't want to use anything but a stable distro in production. So, to recap, yes you can but it is not usually done this way.
    - bboreham 9y ago
      > Your suggestion of doing pip install has the same problem Recalling that I am speaking in a Dockerfile context, no it doesn't. The 'pip install' runs once, on my machine when I create the Docker image. Thank you for the detailed explanation. You have clarified that "just build a deb" is an entirely different exercise.

Denzel 9y ago

> [...] it will unpack everywhere and run. Hate to be pedantic: it will run on an OS that shares the same kernel or newer (assuming backwards compatibility). This type of "run anywhere" statement caused a lot of confusion for me re: Docker when I first started looking into it.

bboreham 9y ago
This is never a problem in practice. All the syscalls for files, sockets, etc., have stayed the same for years. [edit] backstopped by Docker requiring at least 3.10
- Denzel 9y ago
  Sure, and what of the users' applications running in the Docker container. It's just not the type of "run anywhere" I was expecting based on the marketing/hype. And the more people kept saying "package once, run anywhere" the more I began to wonder how Docker was able to accomplish that without being a VM. Short answer: they don't. I'm not saying Docker isn't valuable. It is. I just wish it was documented more readily, without having to sift through jargon, that Docker containers must run on a compatible kernel. Essentially, I found it confusing how Docker was sold as a lightweight VM.

lathiat 9y ago

The thing is that writing a Dockerfile is basically the same thing as packaging a deb/rpm The difference is the language is more friendly to entry level usage. You still had to learn something. And they made 1 file-ish which traditionally most package managements weren't.

bboreham 9y ago
So in a deb I can run "pip install foo"? I have this idea that deb is more file-oriented. Never looked into it properly.
- yebyen 9y ago
  Take a deb and run "ar -xv" on it You will get out a control.tar.gz, data.tar.gz, and debian-binary file which is a text document with a version for something in it. (Not the package version. Maybe DPKG api version.) Now, just look at how simple this structure is and marvel at how quickly you can demystify debs! If you wanted to run "pip install" you could do it in the postinst, a part of control.tar.gz, but this is not the traditional way in a deb. No reason you couldn't do it. Traditionally you should list those pip dependencies as dependencies in control and let debuild or your preferred deb building tool pack it up this way for you, then they can be frozen and will be reproducible through only the package mirrors. (The dependencies are listed as dependencies, and they are also packaged into debs.) I am looking at my heroku_3.99.4_all.deb that I happened to find first, and data.tar.gz contains a single empty directory usr/local/heroku/ for the place that postinst will dump things into (postinst does a wget to some path at https://cli-assets.heroku.com https://cli-assets.heroku.com, and moves a few things around after that.) IMHO this is a terrible deb, because if heroku goes away it will completely bomb out and fail to install. (Then again if heroku does go away, what do you need the heroku client for exactly?) Your suggestion of doing pip install has the same problem, but what's worse? I am a rubyist and I would never question whether you should use bundler to manage your dependencies. Absolutely you should, the package versions in stable distros are atrocious and usually horrifically outdated, and you almost certainly don't want to use anything but a stable distro in production. So, to recap, yes you can but it is not usually done this way.
  - bboreham 9y ago
    > Your suggestion of doing pip install has the same problem Recalling that I am speaking in a Dockerfile context, no it doesn't. The 'pip install' runs once, on my machine when I create the Docker image. Thank you for the detailed explanation. You have clarified that "just build a deb" is an entirely different exercise.