FeM-Wiki

Dokumentations-Wiki der FeM e.V.

Benutzer-Werkzeuge

Webseiten-Werkzeuge


public:technik:gentoo-overlay

Gentoo: FeM-Overlay

Das FeM-Overlay ist ein Portage Overlay für die Gentoo Paketverwaltung. Hier werden Ebuilds und Patches für Software gepflegt, die auf FeM Servern Einsatz findet, so aber nicht im offiziellen Portage-Tree enthalten ist.

Hinweis: Manchmal sind Pakete nur temporär im FeM-Overlay bis die Erweiterungen / Patches in den offiziellen Portage-Tree eingepflegt wurden.

Kontaktadresse: fem-overlay@technik.fem-net.de

Nutzung

Ohne Layman über repos.conf

Diese Variante bietet sich an, wenn man selber am Repository Änderungen vornehmen möchte.

[fem-overlay]
location = /usr/local/overlay/fem-overlay
sync-type = git
sync-uri = https://bitbucket.fem.tu-ilmenau.de/scm/gentoo/fem-overlay.git
auto-sync = yes

Mit eselect-repository

Diese Variante verwendet in der Standardeinstellung ein Clone vom Repository mit zusätzlich generierten Metadaten, was emerge beschleunigt. Empfiehlt sich für Systeme, die das Overlay nur nutzen, aber lokal selbst keine Änderungen hinzufügen.

eselect repository enable fem-overlay

Mit Layman

Das Overlay ist in der offiziellen Liste enthalten.

Hinzufügen des Overlays

layman -a fem-overlay

layman wieder loswerden

# layman Referenzen entfernen
rm /etc/portage/repos.conf/layman.conf
sed -i -e '/source \/var\/lib\/layman\/make.conf/d' /etc/portage/make.conf
sed -i -e '/\*/d' /etc/eix-sync.conf

emerge -C layman

rm -rf /var/lib/layman

eix-sync # oder emerge --sync

Ebuilds einreichen

Für einen schreibenden Zugriff braucht man ein Login im JIRA (und damit im Bitbucket) (Registrierung) und wendet sich dann an fem-overlay@technik.fem-net.de.

Mit einem Bitbucket-Login allein kann man aber bereits sich das Repo forken, eine Änderung in einem Branch commiten und einen Pull-Request erstellen, falls man nicht vollen Schreibzugriff benötigt.

Regeln für erfolgreiche Ebuilds im FeM-Overlay

  • Verwende bei neuen Ebuilds die aktuellste EAPI. (EAPI Cheat-Sheet)
  • Im Files-Ordner sollen keine Archive, sondern nur Skripte und Patches liegen.
  • Alle Ebuilds besitzen einen validen Header

Header

# Copyright 1999-2XXX Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

  • Variablen sollten in der richtigen Standard-Reihenfolge vorliegen

Standard-Reihenfolge

EAPI

inherit

MY_P
DESCRIPTION
HOMEPAGE
SRC_URI

LICENSE
SLOT
KEYWORDS
IUSE

DEPEND
RDEPEND

S
RESTRICT

DOCS

  • Variablen, die evtl. Leerzeichen enthalten könnten müssen bei Verwendung mit Kommandos gequotet werden
    • standardmäßig: ${S}, ${WORKDIR}, ${FILESDIR}, ${DISTDIR}, ${ROOT}, ${D}

Beispiel

# Quoting nicht nötig, da Ergebnis eine Variable ist
S=${WORKDIR}/${PN}

# Quoting nötig, da der Pfad u.U. Leerzeichen enthält
cd "${S}"

  • möglichst eine metadata.xml anlegen mit Informationen, wer das Paket im Overlay betreut und welche Useflags verwendet werden

Beispiel für metadata.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
        <maintainer type="person">
                <email>mamu@fem.tu-ilmenau.de</email>
                <name>Max Mustermann</name>
        </maintainer>
        <use>
                <flag name="ftps">Support for backing up on FTPS</flag>
        </use>
</pkgmetadata>

  • RepoMan zur Prüfung des Ebuilds verwenden
    • Verwendung:
      • repoman manifest (Erstellt Manifest neu)
      • repoman (Prüft alle Ebuilds im aktuellen Verzeichnis)
      • repoman commit (Erstellt einen Commit und fügt Metainformationen hinzu, falls die Prüfung erfolgreich war)

(Ideen aus den Coding-Standards des Sunrise-Overlays.)

Das Overlay wird bei Änderungen mittels Repoman überprüft.

Historie

  • ca. 2008 - Das Overlay wurde angelegt
  • 2017-11-23 - Migration auf Git
public/technik/gentoo-overlay.txt · Zuletzt geändert: 2018/04/05 17:54 von pegro