Apparently when I said updated regularly, I meant updated regularly when I actually have any time to think about any of my projects. Lately we've been working an a pay project which is a great project, and fulfilling, but not very interesting from a programming problem point of view. What we have been doing is over at http://coloradolocalfirst.com and is starting to come together.

However, I have been thinking about a number of things recently. The announcement that kde 4.1 is coming out soon has made me want to work on Open Distro more, and the next real step is to get the odpm daemon (odpmd) up and running. I thought towards that end I would outline some of the basic features that are planned for this. First, an abstract.

Odpmd will be the package repository and maintenance server. This means that it will maintain not only every version of every package, and make them easy to download, but it will facilitate package maintenance and version tracking, as well as source code, patches, and build scripts. Finally it will also serve as the platform that will maintain reliability, likability, etc per package. Basically with odpm on your local machine and at least one up to date odpmd server you have a complete distro maintenance system, including package updates and new installations.

Odpmd will implement it's own protocol, and perhaps serve http as well, or we'll have another connector or program act as a CGI bridge for serving info related web pages and interfaces. The odpm protocol is important for several reasons. First, it allows the server to recommend packages to a client based on dependency metadata. Most current package management systems do not have their own protocol, and it's difficult to do things like this without the client being much more clever. Full databases have to be transfered to the client, who then makes their selections and downloads the packages via ftp or http. In our scheme the server can send minimal listings of packages to the client based on various criteria, such as allowing searches, categorical browsing, or just individual package requests. Since odpmd will understand the package format and metadata it will also be able to save bandwidth and time by sending partial packages or minimal diffs based on the data the client already has.

This also doesn't mean that the client must expose any personal information about it's user, which is a plus. It sends in a list of packages that it currently has installed, and any preferences that are important (download development packages too, download docs, which language to download for localization, etc.). This whole system takes some of the load off of the client and puts it on the server, but the total amount of work done should be greatly reduced, and the amount of bandwidth used should, likewise, be greatly reduced.

So, what will odpmd be maintaining and doing, here's a quick synopsis of features in bullet form:

• Users - odpmd will maintain it's own user database for people who want to contribute to the system. Anyone who wishes to send feedback about a package, submit a patch, bug report, or even a new package will need an account. There will be several roles that are defined to maintain order and reliability in the system. Only trusted users will be able to sign off that a package version is stable, and ready for inclusion in the "stable" area recommended for most users.
• Package Status Categories - The server will maintain broad categories of packages based on the package name, version, and release that is related to the reliability of the package. Packages in the "stable" category have been tested pretty thoroughly, we're pretty sure are non-malicious, and have been signed off on by a trusted user. Packages in the "unstable" category will likely be included in the stable category eventually, but need more testing, generally very little will be wrong with them, but they may not quite be there yet. Packages in the "untrusted" or "unsupported" category may someday be unstable, but basically aren't supported by us. They were submitted by someone "out there" and may be accepted as an unstable package, but may not.
• Package Version Control - This isn't nearly as tricky as source version control. The server will maintain a separate space for every package by name. Each package name must be unique within the system. Each package space may have sub-package spaces within it. Within each space there will be a sub-space per version, and per release of the package. Often the releases differences will vary slightly, and hopefully we can track only the differences. So each package space, if thought of as a directory structure works like: package name / package version / release. A release version is different from a package version. A package version is the version number assigned to the program by it's developers. A release version is basically a count of how many times we've built that package version, fixing configuration issues, adding/changing categories, etc. All related files should be present at each package version (docs, translations, dev files, etc.) but may not be for each release, if they are not present those from the latest release where they are present is used automatically. This will also include the ability to download the full source with patches, build scripts etc and build them right from odpm.
• Ratings and Reports - Odpmd is also the logical place to maintain user ratings of a package for it's stability, it's usability, how much they like it, etc. As well as reports of bugs, missing features, and the like. Some of this data will go towards selecting which packages deserve testing from the unstable and untested/unsupported/untrusted categories.
• Distro Flavor Repos - One thing that has long been planned in Open Distro, is the concept of "flavors." This is basically the idea that by simply selecting a different set of packages, maybe adding some specific configuration, you could build a completely different type of system. For example, with a few tweaks and package choices you could build a general workstation, a general web server, a firewall device, testing and development systems, dedicated database systems, dedicated PBX systems, etc. Basically this just means that we maintain lists of recommended packages to start a system with, and all the systems that would come out of it would be compatible, you could even switch flavors later on. But maintaining those lists in odpmd has some distinct advantages. First off, with a general, minimal "net-install" cd you could install any flavor without even the lists being on the cd. Anyone could download a full set of a certain flavor and build their own cd of it, possibly using packages that they already had on their system to reduce downloading time. And finally, anyone could build their own custom cds using tweaked flavor scripts for specific applications, such as a school system cd.

I'll come back later and discuss some of the intricacies of the protocol and how it will minimize data transfer and work time, and hopefully be able to share other cool features of odpmd as they come about.