

Pkgr.io: Easy way to get a Debian package out of any app - crohr
https://pkgr.io/

======
blinry
I recently discovered the OpenSUSE build service, an automated build service
for RPM and DEB packages:
[https://build.opensuse.org/](https://build.opensuse.org/)

It builds the packages on virtual machines for many different distributions
and 32+64 bit CPUs.

~~~
baldfat
The number one under used service on the planet. It is amazing and should have
revolutionized packaging years ago!!!

Hope people will just "get it" soon!

~~~
gingerlime
I took a look on the website as it does sound promising, but couldn't figure
out what's going on (even with the precursor info on this HN thread).

I could totally "get" why it's the number one under used service. I wish I
could just as easily grasp how to use this service.

pkgr.io does a way better job explaining what the service provide, why it's a
good idea to use it, and even a quick overview of how to use it.

------
mtrn
Packaging is a real pain, kind of a schlep. One project, which solved a lot of
problems for me was
[https://github.com/jordansissel/fpm](https://github.com/jordansissel/fpm).

One edge-case, where fpm cannot help by itself, occurs in the python (w/
C-bindings) world, when your dev and prod environments use different libc
versions. I got around that issue by running fpm inside a VM, which matches
the libc version of the target system.

But it's still not as easy as it can be - so pkgr.io looks promising.

~~~
crohr
OP here, thanks for the comment. fpm is a great tool: PKGR is based on
[https://github.com/crohr/pkgr](https://github.com/crohr/pkgr), which itself
uses fpm. That being said, you indeed need to make sure your build system is
close to your target system, and it is not that easy to package complex apps
with specific dependencies. Generally, (Web) Application packaging does not
have the same needs as OS packaging.

------
bguthrie
Gist of the thing:

    
    
        As a Rails developer, I've become tired of messing with
        ruby versions, gem dependencies, bundle installations,
        deploy-time asset precompilation on my servers,
        etc. ... Basically, what I wanted was a Heroku-like 
        workflow that generates and hosts debian packages, 
        which is what  exactly what PKGR provides.
    

As a customer of Heroku's excellent but rather expensive services, and a fan
of deployment via package management, I'm certainly intrigued.

~~~
wting
I use Dokku (self hosted Heroku) for this purpose:

[https://github.com/progrium/dokku](https://github.com/progrium/dokku)

------
takeoutweight
To offer an alternative, I've personally found checkinstall to be useful for
putting together ad-hoc .deb packages for deployment.

[http://manpages.ubuntu.com/manpages/trusty/man8/checkinstall...](http://manpages.ubuntu.com/manpages/trusty/man8/checkinstall.8.html)

~~~
regularfry
Unfortunately checkinstall has an inconvenient bug on (at least) Debian Wheezy
which makes sudo required for package building under some circumstances.

~~~
infinity0
How so? What goes wrong with `make && sudo checkinstall make install`?

~~~
regularfry
Filesystem translation has a bug: [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=717778](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=717778)
[https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/...](https://bugs.launchpad.net/ubuntu/+source/checkinstall/+bug/78455)

This manifests itself by any "mkdir -p" which requires root in the `make
install` phase failing.

------
jamesgeck0
My first thought was that there was no way I'd want to make my deploys
dependent on yet another random webservice. But it looks like there's a
standalone version, too.
[https://github.com/crohr/pkgr](https://github.com/crohr/pkgr)

------
comice
"Uses Heroku buildpacks to embed all your dependencies within the debian
package. That way, no need to mess with stale system dependencies"

That does mean, however, that it's now your job to rebuild your package
whenever a library gets a security fix. Possibly worth the sacrifice, but an
important one I think people need to understand.

~~~
crohr
OP here. Totally right, the final goal being that a new version of the package
gets automatically rebuilt whenever a buildpack gets updated with a security
fix.

------
drdaeman
Not sure whenever this is a good service or not ( _proper_ Debian packaging is
10% writing scripts 90% reading and conforming to policies), but I believe it
would be really better if it'd be able to produce and maintain "debian" branch
and tags for pbuilder/git-buildpackage, so standard package building practices
would apply.

~~~
derefr
Pkgr (and fpm, the program it uses) is not for shipping a package that people
can install and depend upon as part of their own OS distribution. It's for
using apt-get as your orchestration system, instead of puppet/chef/etc.

You package your application and its dependencies as .debs, create an apt-
mirror containing those debs, add that apt repo to your deploy-targets'
sources.list.d's, "apt-get install yourcorp-system-release", and relax.

~~~
infinity0
They should add a disclaimer that they are not a replacement for _proper
Debian packaging_ then. Lots of whiny people complain about the complexity of
Debian packaging when really they don't understand the requirements for
integrating nicely with every other installed program or potentially-
installable program.

------
jlafon
Well done. All of my questions were answered by browsing the site. +1 for
using SSL everywhere.

------
crymer11
How does this work with assets that need to be served externally, e.g.
uploaded to S3?

~~~
crohr
You have the possibility to add custom before/after hooks, and thus upload
freshly precompiled assets from them, however there is currently no secure way
to encrypt secrets (in your case, S3 credentials). This may come later on (a
la Travis-CI, [http://docs.travis-ci.com/user/encryption-
keys/](http://docs.travis-ci.com/user/encryption-keys/)), but is not a
priority right now.

~~~
crymer11
Are the hooks not run on each instance the package is being deployed to?

~~~
crohr
No, the hooks currently supported are scripts that are run before and after
the slug compilation phase. I don't think you would want to make your package
installation dependent on pre/post install scripts that access the network.

------
jjgreen
Since a .deb, shouldn't this be installed into /usr rather than /opt?

~~~
phaer
No, why? It should be installed in /usr and so on if it conforms to debians
packaging guidelines, otherwise it should stay in /opt.

~~~
nailer
Good point. I guess random apps might, for example, put their binaries outside
bin, or their docs outside of share/docs/myapp

------
comice
Somewhat related is gem2deb:
[https://github.com/lnussbaum/gem2deb](https://github.com/lnussbaum/gem2deb)

Missing the neat config interface of pkgr (and the build service obviously!)
but it's fully supported by Debian/Ubuntu now (used to build almost all of
their ruby app and library packages).

------
otterley
Any plans to do the same for RPM packages? Most enterprises are running a RHEL
variant, not Debian/Ubuntu.

------
krupan
Does this only work for Ruby projects?

~~~
crohr
At launch, only Ruby and Node.js projects are officially supported. But you
can always specify another buildpack in your app's configuration to test with
other runtimes
([https://pkgr.io/doc#buildpack](https://pkgr.io/doc#buildpack)).

------
pekk
Installing dependencies for web apps at the system level is usually the wrong
thing. You may have a deb but now you are prone to conflicts between that deb
and the distro's debs.

~~~
mwcampbell
There are no conflicts, because the application debs put everything in e.g.
/opt/discourse

------
qbonnard
How does it compare to Docker for example?

~~~
crohr
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
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
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.

------
maslam
This solves a real problem. Nicely done. Can't wait to try it out.

------
brokenparser
Do the generated packages pass lintian?

------
tomswartz07
This looks very useful for .deb systems.

Does anyone have any suggestions for other platforms? Perhaps Windows, OSX,
etc?

------
baldfat
Not interested because it only works for deb.

