Re: opinions of snappy packages
Bruce Byfield wrote:
> I am writing an article about the pros and cons of Ubuntu's snappy
> packages, which have recently been ported to a number of major
> If anyone has any experience with them, I would appreciate hearing their
> opinions, especially about how they compare to debs.
While you could definitely make technical comparisons between the .deb
format and the snappy format, a distribution like Debian provides a lot
more than a packaging format. The .deb format in isolation just
represents an archive of files; what makes one into a real Debian
package is Debian Policy. Debian without the .deb format would still be
Debian; Debian without Debian Policy would just be Sourceforge, or
People talk about new container-based packaging formats as ways for
upstreams to deliver "apps" directly, bypassing distributions,
supporting users who can't build software themselves (or upstreams that
only provide binaries), and without dealing with distribution-specific
packaging. Personally, I prefer to get almost all my software from
Debian, because I *like* the consistency and curation Debian provides.
I know if I get a package from Debian that every piece of it will have a
FOSS license. Installing it will not break my system, or override my
preferences. The files within it will install into standard locations.
The software within it will integrate properly with the rest of the
distribution, and with the tools I expect to use to manage it. And if
anything goes wrong, I can easily report bugs in a consistent way, and
expect reasonable handling of those bugs; I can also expect that the
"testing" and "stable" distributions remain free of specific types of
Policy defines the standards that provide consistency across the entire
distribution. Consistency can absolutely be taken too far ("everything
must run on everything else with every possible option!"), but it avoids
Now, that said, I absolutely do want to see better ways to package
software. The overhead of packaging software does still seem higher
than necessary, and massively duplicated between distributions; not all
of that overhead relates to following distribution-specific policies. The
prevalence of language-specific packaging ecosystems, such as npm and
Cargo, suggests a need not fully addressed by distribution packaging
formats. Those formats, in turn, start falling down when they need to
pull in dependencies from outside their language, such as a C library,
which distribution packaging handles just fine.
I'd love to see a well-integrated packaging mechanism that handles all
those cases, including the construction of distributions and embedded
systems, language ecosystems, and "upstream direct" software delivery.
But a packaging format alone won't solve that problem. Anyone thinking
of building a new package ecosystem needs to think long and hard about
their equivalent to Debian Policy.
- Josh Triplett