Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
public:technik:gentoo-overlay [2021/08/14 22:52] – [Regeln für erfolgreiche Ebuilds im FeM-Overlay] Infos über die neue CI und Hinweis zur Nutzung von pkgcheck eingefügt nex | public:technik:gentoo-overlay [2022/12/10 18:57] – [Regeln für erfolgreiche Ebuilds im FeM-Overlay] Hinweis zu automatischer Issue-Zuweisung eingefügt nex | ||
---|---|---|---|
Zeile 68: | Zeile 68: | ||
===== Ebuilds einreichen ===== | ===== Ebuilds einreichen ===== | ||
- | < | + | Für einen schreibenden Zugriff |
- | Für einen schreibenden Zugriff | + | Die ist üblicherweise der FeM LDAP-Zugang. |
- | + | Neue ebuilds können per Fork und anschließendem Merge Request eingericht werden. | |
- | Mit einem Bitbucket-Login allein kann man aber bereits sich das [[https:// | + | Für zusätzliche Berechtigunge (MRs selbst mergen, Issues bearbeiten, etc.) kann man sich an <fem-overlay@technik.fem-net.de> |
- | </del> | + | |
- | + | ||
- | Die bestehenden Anweisungen beziehen sich auf das alte Upstream-Repository, | + | |
==== Regeln für erfolgreiche Ebuilds im FeM-Overlay ==== | ==== Regeln für erfolgreiche Ebuilds im FeM-Overlay ==== | ||
* Verwende bei neuen Ebuilds die aktuellste [[http:// | * Verwende bei neuen Ebuilds die aktuellste [[http:// | ||
+ | * Einzelne eclasses unterstützen nicht die neueste EAPI. In diesem Fall kann die nächstältere benutzt werden. EAPIs, die im Overlay als veraltet markiert sind, //dürfen nicht// in neuen ebuilds benutzt werden. | ||
* Im Files-Ordner sollen keine Archive, sondern nur Skripte und Patches liegen. | * Im Files-Ordner sollen keine Archive, sondern nur Skripte und Patches liegen. | ||
* Alle Ebuilds besitzen einen validen Header | * Alle Ebuilds besitzen einen validen Header | ||
< | < | ||
- | # Copyright 1999-2XXX Gentoo | + | # Copyright 1999-2XXX Gentoo |
# Distributed under the terms of the GNU General Public License v2 | # Distributed under the terms of the GNU General Public License v2 | ||
</ | </ | ||
Zeile 103: | Zeile 101: | ||
DEPEND | DEPEND | ||
RDEPEND | RDEPEND | ||
+ | BDEPEND | ||
S | S | ||
Zeile 111: | Zeile 110: | ||
* Variablen, die evtl. Leerzeichen enthalten könnten müssen bei Verwendung mit Kommandos gequotet werden | * Variablen, die evtl. Leerzeichen enthalten könnten müssen bei Verwendung mit Kommandos gequotet werden | ||
- | * standardmäßig: | + | * standardmäßig: |
< | < | ||
Zeile 118: | Zeile 117: | ||
# Quoting nötig, da der Pfad u.U. Leerzeichen enthält | # Quoting nötig, da der Pfad u.U. Leerzeichen enthält | ||
- | cd " | + | cd " |
</ | </ | ||
- | * möglichst eine metadata.xml anlegen mit Informationen, | + | * möglichst eine metadata.xml anlegen mit Informationen, |
< | < | ||
<?xml version=" | <?xml version=" | ||
Zeile 135: | Zeile 134: | ||
</ | </ | ||
</ | </ | ||
+ | * Manifest erstellen mit pkgdev oder RepoMan: | ||
+ | * '' | ||
+ | * '' | ||
* RepoMan zur Prüfung des Ebuilds verwenden | * RepoMan zur Prüfung des Ebuilds verwenden | ||
- | * Verwendung: | + | |
- | * //**repoman | + | * pkgdev oder RepoMan zum commiten benutzen |
- | * // | + | * '' |
- | * //**repoman commit**// (Erstellt einen Commit und fügt Metainformationen hinzu, falls die Prüfung erfolgreich war) | + | |
* pkgcheck zur Prüfung des Ebuilds verwenden | * pkgcheck zur Prüfung des Ebuilds verwenden | ||
- | * //**pkgcheck scan**// (prüft Ebuilds im aktuellen Verzeichnis auf gängige Konventionen und Fehler) | + | * '' |
(Ideen aus den [[http:// | (Ideen aus den [[http:// | ||
- | Das Overlay wird bei Änderungen mittels [[https:// | + | Das Overlay wird bei Änderungen |
Zudem werden ebuilds per [[https:// | Zudem werden ebuilds per [[https:// | ||
+ | **Sämtliche Pakete müssen erfolgreich die CI-Pipeline durchlaufen, | ||
==== Historie ==== | ==== Historie ==== |