Awesome

NAME

Pakket - An Unopinionated Meta-Packaging System

DESCRIPTION

Pakket is a meta-packaging system that allows you to manage dependencies. It works by trying to avoid work.

What can you do with Pakket?

The main purpose of Pakket is simple: Package applications and libraries. That is all.

Pakket provides a lot of flexibility in how this is done. Here is a list of specific things you can do with Pakket.

• You can generate spec files automatically

  Given an existing API for a language (Perl, Ruby, Python, Rust), Pakket can generate the entire tree of configurations and all the dependencies for a given language.

  If you are looking to convert all your Perl modules, Pakket will simply generate the appropriate specs and requirements.

• You can represent packages closer to their true nature

  Arbitrary packaging systems (e.g., RPM, Deb, etc.) attempt to produce the same packages as other more language-specific packaging systems (Perl's CPAN, Ruby's Gem, Python's Pypi) by reducing the level of detail each package provides.

  Pakket doesn't do that. Pakket attempts to maintain as much information from the source as it can in order to handle more complicated corner cases.

  An example of this is the way different systems compare versions. CPAN and Gem and Pypi handle versions differently, but they are all reduces for the general purpose that RPM or Deb provide.

• You can connect different packages

  Package systems designed specifically for, say Node.js, cannot connect their packages with C dependencies or with Perl dependencies. C programs do not have a packaging system, so C "packages" cannot be connected with anything.

  Because Pakket knows these packages, it can connect them together, even if their own systems can't.

  If you have a Perl binding to a C++ library, you can represent that relationship in Pakket. Pakket will then know how to build the C++ library and build your Perl module binding to that C++ library.

• You can build packages for deployment

  Pakket builds simple package files that can then be delivered to a different machine and used there.

  I mean, why else would we do this?

• You can install packages

  The Pakket installer allows installing a package and its dependencies recursively, from disk or mirrors, and to manage your installation tree.

  Again, this is pretty mandatory.

• Atomic installations

  Did we mention all installations in Pakket are atomic? This means that if you're installing 20 or 20,000 packages and it fails, everything still works. Pakket only activates the new installation once it finished everything successfully.

• Reverts are also atomic

  The Pakket installer allows, by default, to retain multiple installation directories. This means any revert can be simply a single atomic operation of pointing to an older installation.

• Multiple instances

  Most packaging systems can only work with a single installation of a package for the entire system. If you need another copy of a package (same version or a different version), you either can't do it, or the packaging system must create a new package with a name that contains the version (python27, python3, etc.).

  Pakket considers any installation as a single installation instance. You can have as many installations of a package as you want. There can be a global one, a per-user one, a local directory one, a project-specific one, etc.; your pick. You can use one or more than one.

Pakket elements

Pakket has several key elements:

Packages

Everything you wish to build and install is a package. A package can be a program in your favorite language, a library of a language, or anything at all. It will go through a build process you pick and it will get bundled into a parcel.

Categories

All packages have a category. Unlike other systems, Pakket doesn't have a flat structure of packages. They're split into categories.

The category of a package tells Pakket what kind of build system it needs, how to retrieve metadata from the sources, and what to do with it.

For example, packages in the perl category tell Pakket that the builder will need to use one of the available build systems for a Perl module (such as ExtUtils::MakeMaker or Module::Build). It will also use the versioning scheme that Perl has in order to decide which is a newer version and which is older.

Requirements

Pakket makes a difference between a package and a requirement. A package is an existing instance; a requirement is a description. The requirement can have a range of allowed versions for a package, for example.

Spec files

Similar to RPM spec files, Pakket has spec files. You can create them yourself or you can use the generate command to create them for you.

The basic spec file in Pakket contain a package's category, name, and version. It usually contains prereqs as well, keyed by the category and the phase. The phases can be configure (for build-time), test (for when testing the build), and runtime (for using it).

An example of a spec in Pakket in JSON:

{
   "Package" : {
      "category" : "perl",
      "name" : "AnyEvent-YACurl",
      "release" : "2",
      "source" : "https://cpan.metacpan.org/authors/id/T/TV/TVDW/AnyEvent-YACurl-0.20.tar.gz",
      "version" : "0.20"
   },
   "Pakket" : {
      "build" : {
         "make-options" : [
            "OTHERLDFLAGS=-Wl,--verbose -L%PACKAGE_PKG_DIR%/lib -lcurl -lcares -lnghttp2 -lbrotlidec -lzstd -lz -lkrb5"
         ],
         "pre" : [
            "yum -y install krb5-devel",
            "rm -rf /lib/include/curl",
            "rm -f /usr/lib64/pkgconfig/libcurl.pc",
            "/bin/bash -c 'rm -f /usr/lib64/libcurl.*'",
            "/bin/bash -c 'rm -f /usr/lib64/libz.*'"
         ]
      },
      "prereqs" : {
         "build" : {
            "requires" : {
               "perl/ExtUtils-MakeMaker" : "0"
            }
         },
         "configure" : {
            "requires" : {
               "perl/ExtUtils-MakeMaker" : "0"
            }
         },
         "runtime" : {
            "requires" : {
               "native/curl" : "==7.74.0",
               "perl/AnyEvent" : "7.0"
            }
         }
      },
      "version" : "3.060"
   }
}

The package details are in the Package section. The prereqs are in the Prereqs section, under the native or perl categories, under the configure or runtime phase.

Pakket might store these configurations in JSON, but it could also store it in other ways if desired.

Parcels

Parcels are the result of building packages. Parcels are what gets finally installed. You may also call them the "build artifacts" if you wish.

While other packaging systems usually have development packages (or devel or dev), Pakket doesn't differentiate between those. Instead, a Pakket package contains everything created at install time for a built package, including the headers, if such would have been installed.

AUTHOR

Booking.com

COPYRIGHT AND LICENSE

This software is Copyright (c) 2020 by Booking.com.

This is free software, licensed under:

The MIT (X11) License