Policies/Packaging Policy

From KDE Community Wiki
Revision as of 15:47, 8 March 2016 by Neverendingo (talk | contribs) (6 revisions imported: Move Policies from techbase)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

There are two types of packages that may be downloaded from the KDE FTP site: binary packages (rpms, debs, and the like) and source packages. Binary packages are compiled ("runnable") versions of KDE that are built to run on a specific OS or distribution. Source packages are the raw code that makes up KDE. Source packages need to be compiled before they can be used (see Getting Started for further information).

The KDE Project itself only releases and supports the source code packages. Those are the only packages that we have the resources to deal with.

Binary Packages

While we only support the source packages, we recognize that the vast majority of KDE users would prefer (or require) binary packages. As a result, we work with various third-parties to ensure that as many binary packages as possible are built. The procedure works roughly like so:

  1. Several days before a scheduled release, the source packages are "pre-released" to third party packagers
  2. The packagers build KDE into whatever form their OS or distribution uses and uploads them back to the KDE servers
  3. On release day, we move the third party packages to the FTP servers along side the source packages

The identity of the third party packagers makes a great deal of difference in such things as the quality of the package, the speed in which they are uploaded to the servers, how "official" they are, and factors like that. There are two main groups of packagers: those that are the official packagers of a distribution and those that are just devoted users of KDE and a particular distribution or OS.

The former group includes such companies as SUSE, Mandriva, and others. These are all companies that support KDE and want to make sure that their users have quality binary packages of the latest KDE releases. The latter group are users of distributions or operating systems that don't officially support KDE. For instance, it's unlikely that Compaq will make KDE packages for Tru64 anytime soon so any Tru64 packages that you find on the KDE servers are made by a dedicated KDE Tru64 user.

We strongly prefer that the binary packages are made by the distribution vendors whenever possible. This (hopefully) ensures that KDE is as integrated into the distribution as possible and doesn't feel like a "add-on". Only when a distribution or OS doesn't provide packages will we ship a user built package.

Frequently Asked Questions

When will you offer packages for my favorite distribution?

We will ship packages for your favorite distribution when (and only when) your distribution or a dedicated user builds the packages and submits them to us for redistribution. The KDE Project itself does not make any binary packages.

I have a problem with a binary package. Who do I contact?

Please send a note to whoever created the package. Their email address will be included somewhere in the package itself. Do not complain to the KDE official contacts or PR reps as individual packages are out of their scope of knowledge.

Why isn't my favorite distribution's packages on your servers yet?

The speed in which we receive binary packages depends largely on how dedicated to KDE the distribution is and how busy their packagers are at the time. Sometimes the packages just aren't built in time for the release. In those cases, check the servers once a day or so until they do appear.

Who should I email to find out if packages will be made for my favorite distribution?

Send an email to the distribution vendor. Only they will know. Do not ask a KDE representative as they do not know.

What is the difference between the Red Hat "official" and "unofficial" packages

The official packages are built by a Red Hat employee and are very well done if you are using the bleeding-edge Red Hat releases. The unofficial packages are great for those users that don't change their setup very much after installing a particular version.