5 ms·

How does it compare to Docker for example?

pandemicsyn 13y ago
It doesn't really compare. It's: "The easiest way to get a debian package out of any app" Basically you push up to the service and it takes care of building a debian package for you and provides an apt repo to pull from. Usually you end up having to do some permutation of https://wiki.debian.org/HowToPackageForDebian https://wiki.debian.org/HowToPackageForDebian
crohr 13y ago
OP here. For all the goodness offered by Docker to deploy apps, sometimes a good old debian package is all that's needed. The format is widely supported and battle-tested, while Docker requires specificities under the form of kernel version, additional software to install, and additional operational knowledge. In short, if you already have a working Docker installation, you probably don't need PKGR, though nothing prevents you from building your containers by simply apt-get install'ing the app instead of having 10's of RUN commands to install the dependencies.
- mwcampbell 13y ago
  I could see pkgr being useful for creating an on-premises "enterprise" version of a web app, in situations where the target customers would like to deploy it on their own Debian or Ubuntu machines. Docker is a bit too cutting edge for that scenario.
  - jpdlla 13y ago
    This is exactly the same scenario I had in mind. This would allow projects to have an easier way to distribute some kind of Enterprise version of a web app. Will definitely take a look.
jafaku 13y ago
Yeah, I don't think I will ever need stuff like what OP created now that we have Docker. Containerize all the things!
- mwcampbell 13y ago
  It seems to me that your response basically amounts to "out with the old, in with the new." I think it's better to carefully evaluate the tradeoffs of different solutions than to assume that either the old way or the new way is automatically better. In this case, containers have definite merits. For example, you can be sure you're not inadvertently dependeing on something that happens to be installed on your systems but may not be explicitly declared as a dependency of your package. On the other hand, is containerization going to make it harder for admins to deploy security updates, especially for things that are usually system-wide libraries in the conventional distro packaging model, like OpenSSL?
  - npsimons 13y ago
    I would go so far as to say that while containerization is incredibly useful, it's being used as a bandage for a lot of broken systems. Take for instance one of the most popular platforms for using Docker and other containers on: OSX. Looking there, package management is a mess at best. Those of us long time Debian users can appreciate having a service for those (very rare) situations in which something is not already (very well) packaged. Making sure that you're not inadvertently depending on something is as easy as "apt-get install" on the target machine (usually your webserver that is running the same version of Debian as your dev machine).
    - shykes 13y ago
      > Those of us long time Debian users can appreciate having a service for those (very rare) situations in which something is not already (very well) packaged. Hi, I created Docker and am also a long-time Debian user. I disagree with your assertion that containers are a bandaid for broken systems. Containers take the best parts of solid system packaging, and make them relevant again for software being written today - not 20 years ago. Before starting Dotcloud I used to work at a Debian-only shop, where .debs were the only accepted vehicle for software changes, company-wide. This allowed for quality ops based on a foundation of "immutable things". But as the stack grew in complexity and the infrastructure and team grew in scale, that became a nightmare. Here's what kills Debian packages as a universal unit of software delivery: 1) Versioning hell. When 15 developers are each deploying 10 slight variations of a build, in different combinations, on the same underlying set of machines, how do you express that as deb packages? As we found out the hard way, the answer is: you can't, not in any sane way. 2) The tooling sucks for developers. Walk up to a random developer and give them a 5mn pitch on how to package their software as a debian package, the right way. There's reason pkgr.io and fpm exist. They are bandaids around a fundamentally flawed developer experience. Side note: sometimes I wish Docker wasn't so popular and hyped. It seems that for a portion of the engineering population, anything popular is necessarily poorly designed, by people unaware of the state of the art. As it turns out, we are very aware of the state of the art, have dealt with it for many years, and argue that there is room for improvement. Just my 2 cents.

It doesn't really compare. It's: "The easiest way to get a debian package out of any app" Basically you push up to the service and it takes care of building a debian package for you and provides an apt repo to pull from. Usually you end up having to do some permutation of https://wiki.debian.org/HowToPackageForDebian https://wiki.debian.org/HowToPackageForDebian

crohr 13y ago

OP here. For all the goodness offered by Docker to deploy apps, sometimes a good old debian package is all that's needed. The format is widely supported and battle-tested, while Docker requires specificities under the form of kernel version, additional software to install, and additional operational knowledge. In short, if you already have a working Docker installation, you probably don't need PKGR, though nothing prevents you from building your containers by simply apt-get install'ing the app instead of having 10's of RUN commands to install the dependencies.

mwcampbell 13y ago
I could see pkgr being useful for creating an on-premises "enterprise" version of a web app, in situations where the target customers would like to deploy it on their own Debian or Ubuntu machines. Docker is a bit too cutting edge for that scenario.
- jpdlla 13y ago
  This is exactly the same scenario I had in mind. This would allow projects to have an easier way to distribute some kind of Enterprise version of a web app. Will definitely take a look.

jafaku 13y ago

Yeah, I don't think I will ever need stuff like what OP created now that we have Docker. Containerize all the things!

mwcampbell 13y ago
It seems to me that your response basically amounts to "out with the old, in with the new." I think it's better to carefully evaluate the tradeoffs of different solutions than to assume that either the old way or the new way is automatically better. In this case, containers have definite merits. For example, you can be sure you're not inadvertently dependeing on something that happens to be installed on your systems but may not be explicitly declared as a dependency of your package. On the other hand, is containerization going to make it harder for admins to deploy security updates, especially for things that are usually system-wide libraries in the conventional distro packaging model, like OpenSSL?
- npsimons 13y ago
  I would go so far as to say that while containerization is incredibly useful, it's being used as a bandage for a lot of broken systems. Take for instance one of the most popular platforms for using Docker and other containers on: OSX. Looking there, package management is a mess at best. Those of us long time Debian users can appreciate having a service for those (very rare) situations in which something is not already (very well) packaged. Making sure that you're not inadvertently depending on something is as easy as "apt-get install" on the target machine (usually your webserver that is running the same version of Debian as your dev machine).
  - shykes 13y ago
    > Those of us long time Debian users can appreciate having a service for those (very rare) situations in which something is not already (very well) packaged. Hi, I created Docker and am also a long-time Debian user. I disagree with your assertion that containers are a bandaid for broken systems. Containers take the best parts of solid system packaging, and make them relevant again for software being written today - not 20 years ago. Before starting Dotcloud I used to work at a Debian-only shop, where .debs were the only accepted vehicle for software changes, company-wide. This allowed for quality ops based on a foundation of "immutable things". But as the stack grew in complexity and the infrastructure and team grew in scale, that became a nightmare. Here's what kills Debian packages as a universal unit of software delivery: 1) Versioning hell. When 15 developers are each deploying 10 slight variations of a build, in different combinations, on the same underlying set of machines, how do you express that as deb packages? As we found out the hard way, the answer is: you can't, not in any sane way. 2) The tooling sucks for developers. Walk up to a random developer and give them a 5mn pitch on how to package their software as a debian package, the right way. There's reason pkgr.io and fpm exist. They are bandaids around a fundamentally flawed developer experience. Side note: sometimes I wish Docker wasn't so popular and hyped. It seems that for a portion of the engineering population, anything popular is necessarily poorly designed, by people unaware of the state of the art. As it turns out, we are very aware of the state of the art, have dealt with it for many years, and argue that there is room for improvement. Just my 2 cents.