Ark Linux packaging rules

Ark Linux "wanna be" Packaging Rules
Version: 0.1.0alpha3
1. Introduction
This are a set of rules that should be followed when making Ark Linux (RPM) packages. The objective of this rules is to bring order among the packages to easy administration and at the same time, being user friendly. This rules may have stantments for any part of the packages, name, description, spliting, building, etc.
2. Categorizing
The category of the packages should be handled with carefull having in mind various different aspects:
* It has to be user friendly.
* It has to be application friendly (for the installer, remover and updater applications, so, they can be user friendly as well)
* There well be 4 categories: Application, Libraries, Text Applications (or maybe Programs or Provider Applications) and System.
2.1. The Application category
The Application category has special rules. Every package in the Application category will be one and only one application (see Splitting) containing user friendly name, summary and description. It should also provide a .desktop files for the K menu which should be added if not provided already by the source package and the sub-category on the Application category should resemble the K menu.
The Application category is what the average user will normally work with, install and uninstalling applications so the user won't have to handle libraries or Text Applications (this is based in the fact that average users will only use GUI applications)
2.1.1. Plug ins
Applications that comes with plug ins might or might not separated depending on how important those plug ins are for the application. If the application is totally un-useful without the plug ins, the plug ins may remain in the main package, or one plug in may remain in the main package (what would be considered the default plug in) or the application should depend on having at least one plug in installed. If the application can run and be useful without the plug ins, plug ins might be just packaged separatly and that would be the best thing to do. The plug ins would go in the same category as the application and the name of the package would be Application-plugin to show the dependency in a user friendly way.
If a package is containing only of plug ins, they should be packaged exactly as explained above and put in the same category as the application they work for. In case they're generic, they could stay in the Applications category (or should they go to Applications/Plug Ins ?).
When an application strongly depends on plug ins provided by other packages, the description of the application should explain it.
2.1.2. Examples
A posible fictitious example would be, the application Kopete inside kdenetwork source package of KDE. The name of the package will be Kopete and not kopete and to the user should be shown as Kopete, the summary and the descript should be user friendly and the category of the package should be Applications/Internet/Instant Messaging and it should be splitted from the rest of the kdenetwork package. All the plug ins of Kopete should go into separated packaged, like Kopete-Jabber, Kopete-MSN, Kopete-ICQ, etc. and in the description of the Kopete package that should be explained. Kopete might depend on one plug in (any) or may include a plug in (the jabber plug in would be the choice) or may depend on that plug in.
2.2. Other categories
There are other categories:
* Text Applications
* Libraries
* System
and they will hold packages that the user will never know about (or even care).
The idea is that all the packages on these categories should depend on another package (on these categories or on Applications), so, a un-installing application could un-install all the packages on these categories that are not needed by any other package safely reducing the HD space needed, the time of upgrading and the bandwith on the servers.
2.2.1. Text Applications
Text applications are those that doesn't have a GUI and that the user don't use directly but through another GUI application, examples would be: mplayer, transcode, gcc, etc.
2.2.2. Libraries
Libraries is simple for libraries that are used by GUI applications, libraries like kdelibs, libvorbis, etc.
2.2.3. System
System is for really low level packages that are nore Text Applications neither Libraries, like the kernel.
3. Splitting
Packages in the Application category that contain more than one binary (executable) should be splitted leaving one package for each binary (unless one binary trully is, a helper of another one and then, they can be packaged together).
Packages in the other categories should be splitted using common sense ;)
4. Versions
Different programs use diferente schemes for version, being the most normal the three integer separated by dots, like 0.8.2, 1.5.2, 10.45.34. This are the simplest cases and if a program has that versioning scheme, that version should be used in the rpm and the release number should be added.
The porpouse of the release number is, among other things, to be able to re-build the rpm changing some things without needing to change the version of the application, so, the first build of an application version 0.8.2 would be 0.8.2-1, and then 0.8.2-2 and so on. But as there are a lot of rpm based distributions, to diferentiate Ark Linux rpms from others we also add ark at the end, converting it in 0.8.2-1ark, 0.8.2-2ark, 0.8.2-3ark and so on, until the version changes and the release counting is reseted: 0.8.3-1ark.
In the case there are more information in the version, like the adition of an alpha, beta, rc, pre, test, etc after the version, to avoid problems with rpm thinking that 0.8.2pre1 is newer than 0.8.2 the extended part of the version should be specified in the release. As the first release of 0.8.2 would be 0.8.2-1ark, for pre releases, we use 0 for the release number following by the extended part of the version and followed by the re-release (after all, we might want to make several releases of 0.8.2pre1) leading to the following version scheme 0.8.2pre1 would become 0.8.2-0.pre1.1ark being 0.8.2 the version and 0.pre1.1ark the release, the following release would be 0.pre1.2ark and so on.
5. Buildroot, prefix, etc
Prefix should be set to %{_prefix} and BuildRoot to %{_tmppath}/%{name}-%{version}-%{release}-root