As part of the 2014 USENIX Release Engineering Summit West, I presented a talk about packaging software and what's wrong with current trends.
Here's the abstract:
Reliably distributing software is a notoriously difficult problem, and almost every operating system and programming language vendor has tried to solve it. This has led to a herd of packaging systems, almost none of which are cross-compatible; some manage system-level software, while others focus on extending their own language (often by trampling on system-level software). And like all competing standards, every packaging system comes with its own sharp corners, dull edges, and hidden idiosyncrasies to deal with along the path to packaging happiness. In an attempt to answer the question "How do I install this software and ensure that its dependencies are fulfilled?", some novel solutions have begun to see popular adoption. But a lot of these newer tools and techniques tread the same ground as their predecessors while overlooking the lessons that were learned along the way.
I'll talk about the state of native packaging systems on some popular platforms (Debian/Ubuntu, RHEL/CentOS/Fedora, and Mac OS X), packaging systems for popular languages (Ruby, Python, Perl, and Node) and the ways that developers are attempting to work around the limitations of these systems. I'll review the reasons that tools like curlbash, FPM, and omnibus packages have become popular by sharing lessons I've learned while working through these systems. While this will be an amusing presentation, I'll show how native packages can address the concerns that have pushed Release Engineers and Developers away. I will also talk about what native packaging systems can learn from the next generation of packaging tools.
The original abstract is available here:
https://www.usenix.org/conference/ures14west/summit-program/presentation/mckern
10. Distributing software sucks
Shipping new platforms is so hard
Cross-platform packaging is so hard
Unpredictable user-space is so hard
Moving the packaged bits is so hard
12. Who among us knows this pain?
sad@roberto Downloads $ wget -‐-‐quiet http://
ftpmirror.gnu.org/gcc/gcc-‐4.9.1/gcc-‐4.9.1.tar.bz2
sad@roberto Downloads $ tar xjf gcc-‐4.9.1.tar.bz2
sad@roberto Downloads $ cd gcc-‐4.9.1/
sad@roberto Downloads $ ./configure
./configure: line 532: sed: command not found
./configure: line 1371: sed: command not found
./configure: line 1920: sed: command not found
./configure: line 2291: sed: command not found
configure: error: cannot run /bin/sh ./config.sub
./configure: line 361: sed: command not found
./configure: line 310: sort: command not found
13. This was a problem because
the customer's time has value
17. Dependency management
calculon ~ # apt-‐get install cmake
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
cmake-‐data emacsen-‐common libarchive12 libnettle4
libxmlrpc-‐core-‐c3
The following NEW packages will be installed:
cmake cmake-‐data emacsen-‐common libarchive12 libnettle4
libxmlrpc-‐core-‐c3
0 upgraded, 6 newly installed, 0 to remove and 51 not
upgraded.
25. .rpm
• Managed by the recursively named
"RPM Package Manager" & yum
• cpio compressed binaries & text files
• Post-installation tasks are shell scripts
26. .deb
• Managed by dpkg & apt, the
"Advanced Package Tool"
• ar compressed package with two
gzipped tarballs & a small text file
• Post-installation tasks are shell scripts
27. Mac .pkg
• Used by Mac OS X, and often delivered
in a .dmg (disk image) or a .zip file
• xar compressed archive, containing a
binary file, two archives, and an XML
document
• post-installation tasks are still
shell scripts
28. About all those post-install
shell scripts
Maybe they're not that safe, but the
surface area of this problem is big.
That doesn't mean we needed "dash"
29. Ruby .gem, Python .egg,
and Node .npm
• These are library managers with
delusions of grandeur
• Reuses the "download, decompress,
configure, build, install" patterns,
which hasn't got much spam in it
• Constant compilation is a bummer
30. What about... ?
#realtalk
We only have 45 minutes, and I hope
you're going to have some questions for
me to evade
36. Full Disclosure
• Puppet Labs does use the curl|bash
technique as an option for our PE
agent installation
• If you don't trust your own Puppet
Master, who do you trust?
• (ALL THE COOL KIDS WERE DOING IT)
38. curl | bash often assumes
• There is no air-gap
• Every request is a safe & sane request
• That HTTPS is good enough
39. curl | bash often forgets
• >100% Broadband coverage
• Mirrors exist
• HTTPS secures transport, not content
40. curl | bash totally ignores
• The benefits of reusability
• The fragility of shell scripts
• The fragility of shells
41. Security is hard
• RVM recently introduced hand-rolled
GPG signing*
• Thread had 48 comments within a
week, almost universally about the
implementation
• Broke semver, automation, and hearts
* https://github.com/wayneeseguin/rvm/issues/3105
43. Isn't that from Chef?
• Sure, but so is Test Kitchen
• Builds packages while still controlling
the entire dependency stack
• Lots of love from users with
complicated dependency stacks
44. Omnibus is one way to skin
the entire cat
• Abstracts (instead of removes)
dependency management
• Only builds packages for the platform
it's installed on
• You're going to want to know Ruby
46. Effing Package Managers
•General purpose swiss-army knife of
package building
•Works around a lot of the shortcomings
of existing package managers
•Jordan Sissel is a SAINT (Shout out to
#hugops!)
47. "Common packaging patterns, a
distaste for existing packaging
practices, and some hate-driven
development yielded FPM! Add
some amazing contributions in
code, bugs, features, and support
from the community and boom we
have modern FPM."
Jordan Sissel
My inbox, Oct 10 2014
48. Effing FPM
• Swiss army knives are rarely the best
tool for a given job
• General purpose in this case means a
lot (~150ish) of command line flags
• Still infinitely better than curl | bash
50. RPM Packaging can
be tough
• RPM Spec files are weird
• Kind-of M4, kind of Shell, all obtuse
• Oh, and kind-of Make; only kind-of
• Sort-of competing RPM standards
51. Deb Packaging can feels
like penance
• "debian/" directories are outright
hostile to man & beast alike
• Debian "Helpers" usually don't
• dpatch can use unified diffs (sane) or
shell scripts (what?!)
52. Conflation of purpose
• Some library managers try to install
executables, e.g. gem, pip, npm
• Remember when I said "delusions of
grandeur"?
(Google Image Search was kind of
useless here)
53. But really, I just have a
hypothesis!
• Developers love solving new problems
• Sometimes they confuse their
problems for the customer's problems
• Maybe packaging isn't a solved
problem yet, but it's close
55. Sometimes the only choices you have
are bad ones; but you still have
to choose.
56. TL;DR: this problem is
(mostly) solved
Stop writing new installers
from scratch
Give your customers the best
packages possible
Don't forget Pareto
(any number of 80/20 rules)
57. Thank you
You're wonderful. Thank you for letting
me rant at you for as long as you did.
mckern@puppetlabs.com
@the_mckern