openSUSE:Richtlijnen voor naamgeving van pakketten
Inhoud
Gemeenschappelijke tekenset voor pakketnamen
Terwijl openSUSE een internationale gemeenschap is, is het voor consistentie en bruikbaarheid, nodig om een gemeenschappelijke tekenset voor pakketnamen te hebben.
Speciaal voor alle openSUSE pakketten mag de naam alleen de volgende ASCII tekens bevatten. Hieronder volgen deze tekens:
abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789-._+
When Upstream Naming is outside of the specified character set
OpenSUSE herkent dat het vertalen van tekst naar een bepaalde ASCII karakter set (ook transliteration genoemd), moeilijk kan zijn. Daarom zal de OpenSUSE pakket onderhouder, wanneer de gekozen naam uit de ASCII karakter set valt, eerst de ontwikkelaar contacteren voor die softwar en hem vragen om een transliteratie van de naam uit te voeren om het pakket in OpenSUSE te gebruiken.
Als (en enkel als) de ontwikkelaar de mogelijkheid niet heeft, niet wilt, of een getranslitereerde naam aan te bieden, dan zal de OpenSUSE pakket maken ervoor moeten kiezen om oftewel zelf een tansliteratie uit te voeren, of wel het pakket uit consideratie in OpenSUSE te halen.
Wanneer beslist wordt hoe men een pakketnaam moet translitereren, dan zal de OpenSUSE pakketmaker zoeken of andere distributies reeds een naam voor dat pakket hebben, en die dan gebruiken.
Getranslitereerde pakketten kunnen de originele, niet-getranslitereerde naam bevatten.
| Dit artikel is nog maar gedeeltelijk vertaald. Als u mee wilt helpen met vertalen lees dan Wiki vertalen naar het Nederlands. |
Algemene benaming
When naming a package, the name should match the upstream tarball or project name from which this software came. In some cases, this naming choice may be more complicated. If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision.
Additionally, it is possible that the upstream name does not fall into the Common Character Set . If this is the case, refer to: When Upstream Naming is outside of the specified character set .
Separators
When naming packages for openSUSE, the maintainer must use the dash '-' as the delimiter for name parts. The maintainer must NOT use an underscore '_', a plus '+', or a period '.' as a delimiter.
There are a few exceptions to the no underscore '_' rule.
- httpd, pam, and SDL addon packages are excluded, refer to " Addon Packages (httpd, pam and SDL) ".
- packages that are locale specific, and use the locale in the name are excluded, refer to " Addon Packages (locale) ".
- packages where the upstream name naturally contains an underscore are excluded from this.
Examples of these packages include:
java_cup libart_lgpl microcode_ctl nss_ldap sg3_utils
If in doubt, ask on opensuse-packaging mailing list list.
Verschillende pakketten met dezelfde basisnaam
For many reasons, it is sometimes advantageous to keep multiple versions of a package in openSUSE to be installed simultaneously. When doing so, the package name should reflect this fact. One package should use the base name with no versions and all other addons should note their version in the name. There are some exceptions where all packages have version attached to the package name (i.e. there is no package without version in the name).
Voorbeelden:
autoconf or sqlite occasionally have multiple versions in openSUSE for backwards compatibility.
The most current version of autoconf has Name: autoconf
The older 2.1.3 version of autoconf has Name: autoconf213
The packages for 3.x series of sqlite have Name: sqlite3 and Name: sqlite3-devel
The packages for 2.x series of sqlite have Name: sqlite2 and Name: sqlite2-devel
Note that we do not use delimiters in the name in this situation, we remove the period '.' from the version number and attach it to the name.
The special case which is treated differently are shared libraries. There is a separate Shared Library Naming and Packaging Policy describing how to handle them.
Hoofdlettergevoeligheid
In openSUSE packaging, the maintainer should use his/her best judgement when considering how to name the package. While case sensitivity is not a mandatory requirement, case should only be used where necessary. Keep in mind to respect the wishes of the upstream maintainers. If they refer to their application as "ORBit", you should use "ORBit" as the package name, and not "orbit". However, if they do not express any preference of case, you should default to lowercase naming.
The exception to this is for perl module packaging. The CPAN Group and Type should be capitalized in the name, as if they were proper nouns . (Refer to Addon Packages (perl modules) for details.)
Spec bestandsnaam
The spec file should be named using the %{name}.spec scheme. If your package is named foo-1.0-1.src.rpm, then the spec file should be named foo.spec.
Bestaande pakketten vervangen/hernoemens
In the event that it becomes necessary to rename or replace an existing package, the new package should make the change transparent to end users to the extent applicable. If a package is being renamed without any functional changes, or is a compatible enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes), provide clean upgrade paths and compatibility with:
Provides: oldpackagename = %version Obsoletes: oldpackagename < 1.0
If a package supersedes/replaces an existing package without being a compatible enough replacement as defined in above, use only the Obsoletes from above.
Example
- walkman being renamed to ipod
- ipod is compatible with walkman
- the last walkman package version was walkman-1.4
This should be the content of ipod.spec
Provides: walkman = %{version}
Obsoletes: walkman < 1.0
The Provides should be assumed to be deprecated and short lived and removed in the distro release after the next one. For packages that are not usually pulled in by using the package name as the dependency such as library only packages (which are pulled in through library soname depenencies), there's usually no need to add the Provides.
SubPakketten Documentatie
Large documentation files should go in a subpackage. This subpackage must be named with the format: %{name}-doc .
The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity.
Addon Pakketten (Algemeen)
Als een nieuw pakket wordt aanzien als een "addon" pakket dat de functionaliteit van een reeds bestaand pakket uitbreidt zonder nuttig te zijn als alleenstaand programma, dan zal zijn naam aan de volgende voorwaarden moeten voldoen.
Het nieuwe pakket ("child") zal in zijn naam voorafgegaan moeten worden door het "parent" pakket in het volgende formaat:%{parent}-%{child}.
Voorbeelden:
gnome-applet-netmon (Netmon applet voor GNOME, hoort bij GNOME) php-adodb (adodb functionaliteit voor php, hoort bij php) python-twisted (de twisted module voor python, hoort bij python/) xmms-cdread (direct cd lees functionaliteit voor xmms, hoort bij xmms)