Blogging Ottinger (tim)

Okay, it’s still pretty new and tender, but PDK/CL is a mighty interesting thing. It will probably change the world, once people understand what it really is.

1. Component-based Linux
   Rather than deal with individual packages, you can deal with functionality in chunks. This makes it much easier to build a custom distribution. The PDK toolkit is good already for generating installers, deb repos, and ISOs. Sam is working on making it very useful in the rpm world too. In a little while, PDK will be come the fastest and easiest way to build a Linux.

   And you can create your own components, too.

2. Version Control for Distributions.
   Something hard to do prior to PDK was to have your distro’s definition checked into version control so it’s easy to roll back, branch, etc. Now it will be very easy. You wouldn’t write code without VC, so why generate distributions without it?
3. Leverage for Traditional Package Sources

   You can configure “channels”, which are connections to remote package sources (like apt repositories and big piles of files). That means you can build components and resolve the package references against Sarge, or Sid, or Ubuntu, or whatever you wish. It also means you can publish your piles of files as channels for PDK users to use in their work. You can share packages as well as components. One may continue providing value by being a good source of packages, including update packages. The ‘channels’ feature should make it easier to incorporate updates from services like PTS.

4. Distributed Version Control for Distributions

   Not only VC, but DVC. That means that sharing with friends and strangers is much easier. This toolkit makes it possible to have an open-source (or closed-source) eco-system (pardon the E word). You can merge, branch, change all you want. Just as you could always do, but now with three-way and n-way merges. The system has no “top”, so everyone is a peer. This also makes it nice when there is a canonical source for some components, and you want to merge it in and take updates.

5. Metadata
   There is information about components and packages which isn’t easy (sometimes even possible) to derive from packages. It seems to make sense to have components step into the gap and carry the kinds of information you might have had in comps.xml or some other mechanism. This is just continuing the work done earlier on anaconda and CL, I suppose.
6. Installer customization

   I know that there is a tremendous amount of work going on in the area of generating installers and images, and making them easier to customize and modify. Basically, it can be done through metadata. This is getting active development at Progeny.

7. Extensions

   Well, it’s Python to begin with, so extension isn’t hard. But also there is a (rather pedestrian) plugin interface. One can write functions in python modules, and make them part of the pdk command line and shell. That means that open developers can add features as plugins for the world, and proprietary developers can have internal-only or for-pay extensions. We expect most to be in-house only. After all, you can add free features to PDK outright, since it’s open source.

That’s just a little of the potential we are talking about. There is much more. It has good ramifications for free and paid package and component sources. It is good for the distro developer, and gives the community a new level of collaboration. That’s more exciting than “a Progeny product.”