Schemata

aus openSUSE, der freien Wissensdatenbank

(Weitergeleitet von Muster)

Dieser Artikel ist lediglich eine reine Übersetzung der Vorschläge, welche Andreas Jaeger im englischsprachigen Wiki von openSUSE.org gemacht hat.

Inhaltsverzeichnis

Schemata (engl. Patterns)

Zur Zeit werden in SUSE Linux 10.1 (und früheren Veröffentlichungen) in YaST Selektionen zur Gruppierung und einfachen Installation von zusammenhängender Software benutzt.

Unsere Entwickler haben nun das Konzept der Selektionen erweitert und nennen diese nun Schemata (engl. Patterns).

Was sind Schemata?

  • Schemata enthalten eine Liste von Software welche installiert werden soll
  • Diese Software-Liste enthält Pakete, die
    • benötigt werden (must-have)
    • empfohlen werden (should-have)
    • vorgeschlagen werden (may-have)
  • Schemata definieren eine Funktion die das System haben sollte. Sie erreichen dies über eine direkte Benennung benötigter Pakete oder durch das Gruppieren von Unterschemata (sub-patterns) oder durch eine Kombination beider Ansätze. Dadurch wird die riesige Liste an installierbaren Paketen in Blöcke gepackt, die (fast) beliebig kombiniert werden können. Durch die Auflistung jedes und aller RPMs in einem (idealerweise: genau einem) Schema werden die RPMs Funktionen zugeordnet. Daraus ergibt sich eine Antwort auf die häufig gestellte Frage: "Warum ist dieses Paket installiert?"
  • In Zukunft würden wir damit gerne auch die Arbeitsabläufe optimieren. Wenn Sie bspw. das (imaginäre) Schemata LDAP-Server auswählen, werden die Abläufe der LDAP-Konfiguration während der Installation aufgerufen.
  • Schemata können in Rollen wie bspw. "Entwicklung" oder "Desktop" gruppiert werden.
  • Schemata können auch andere Schemata benötigen. Sie verfügen über den gleichen Satz von (möglichen) Abhängigkeiten wie sie Paketen zu eigen sind. So können sie andere Schemata ebenso veralten lassen (also ersetzen) oder mit ihnen in Konflikt treten; oder von Sprachen abhängig sein usw.
  • Zusatzprodukte können zusätzliche Schemata enthalten.
  • Schemata können zwischen top-level/user-visible und internal/non-user-visible Schemata unterschieden werden (ein Schema kann andere benötigen, welche aber nicht sichtbar sind) - dies sind Implementierungsdetails der Schemata.

Von Selektionen zu Schemata

Direkt nach 10.2 Alpha2 würde ich (Andreas Jaeger) gerne zu Schemata wechseln. An Stelle einer einfachen Umbeschreibung der existierenden Versionen würde ich gerne von Grund auf neu Starten und mit allen überlegen, welche Schemata wir haben sollten.

Selektionen in SUSE Linux 10.1

Zur Zeit haben wir folgende Selektionen:

  • Grafisches Grundsystem (Graphical Base System)
  • KDE Desktop-Umgebung (KDE Desktop Environment)
  • KDE komplett (All of KDE)
  • GNOME-System (GNOME System)
  • Hilfe und Support-Dokumentation (Help and Support Documentation)
  • Büroanwendungen (Office Applications)
  • Spiele (Games)
  • Multimedia
  • Voice over IP
  • Xen-Virtualisierung (Xen Virtualization)
  • Einfacher Webserver mit Apache2 (Simple Web Server with Apache2)
  • LDAP Server und Werkzeuge (LDAP Server and Tools)
  • Netzwerk und Server (Network and Server)
  • Laptop
  • Mobile Computernutzung (Mobile Computing)
  • C/C++ Compiler und Werkzeuge (C/C++ Compiler and Tools)
  • Kernel Entwicklung (Kernel Development)
  • KDE Entwicklung (KDE Development)
  • GNOME Entwicklung (GNOME Development)
  • Tcl/Tk-Entwicklungssystem (Tcl/Tk Development System)
  • Java
  • Erfahrene Benutzer (Experienced User)
  • LaTeX, SGML und XML
  • Fonts
  • Mono/CLR
  • Nicht-Open Source Pakete

Schemata für openSUSE 10.2

Alpha5 wird folgende Schemata verwenden:

  • Basistechnologien
    • 32bit: 32Bit-Laufzeitumgebung (nur auf ppc64, x86-64)
    • 64bit: 64Bit-Laufzeitumgebung (nur auf ppc)
    • apparmor: Novel AppArmor
    • base: openSUSE Basissystem
    • console: Werkzeuge für die Konsole
    • laptop: Laptop
    • x86: x86-Laufzeitumgebung (nur auf ia64)
    • yast2_basis: YaST2 Systemadministration
  • Grafische Umgebungen
    • gnome: GNOME-Arbeitsumgebung
    • kde: KDE-Arbeitsumgebung
    • xfce: Xfce-Arbeitsumgebung (nur ftp und DVD)
    • x11: X-Fenstersystem
    • fonts: Schriftarten
  • GNOME Arbeitsfläche
    • gnome_admin: GNOME-Administrationswerkzeuge
    • gnome_basis: GNOME-Basissystem
    • gnome_ide: GNOME-Entwicklungsumgebung
    • gnome_games: GNOME-Spiele
    • gnome_imaging: GNOME-Grafikanwendungen
    • gnome_laptop: GNOME-Laptop
    • gnome_multimedia: GNOME-Multimedia
    • gnome_office: GNOME-Büro
    • gnome_utilities: GNOME-Dienstprogramme
    • gnome_xgl: GNOME-Arbeitsflächeneffekte
  • KDE Arbeitsfläche
    • kde_admin: KDE-Administrationswerkzeuge
    • kde_basis: KDE-Basissystem
    • kde_ide: KDE-Entwicklungsumgebung
    • kde_edutainment: KDE-Lernprogramme
    • kde_games: KDE-Spiele
    • kde_imaging: KDE-Grafikanwendungen
    • kde_internet: KDE-Internet
    • kde_laptop: KDE-Laptop
    • kde_multimedia: KDE-Multimedia
    • kde_office: KDE-Büro
    • kde_system: KDE-System
    • kde_utilities: KDE-Dienstprogramme
    • kde_xgl: KDE-Arbeitsflächeneffekte
  • Arbeitsflächenfunktionen
    • games: Spiele
    • imaging: Grafikanwendungen
    • remote_desktop: Entfernte Arbeitsflächen
    • xml: Werkzeuge zur Bearbeitung von XML und LaTeX
  • Server-Funktionen
    • dhcp_dns_server: DHCP- und DNS-Server
    • directory_server: Verzeichnis-Server (LDAP)
    • file_server: Datei-Server
    • gateway_server: Internet-Gateway
    • lamp_server: Web- und LAMP-Server
    • mail_server: E-Mail- und News-Server
    • misc_server: Verschiedene Server
    • network_admin: Netzwerkverwaltung
    • print_server: Druck-Server
    • xen_server: Xen Virtual Machine Host Server
  • Nicht-OSS Software
    • non_oss: Verschiedene nicht quelloffene Software (nur auf den NON-OSS-Medien)
    • non_oss_java: Java Environment (only on NON-OSS Media)
  • Entwicklung
    • devel_basis: Basisentwicklung
    • devel_C_C++: C/C++-Entwicklung
    • devel_gnome: GNOME-Enticklungt
    • devel_ide: Integrierte Entwicklungsumgebungen
    • devel_java: Java-Entwicklung
    • devel_kernel: Linux- Kernel-Entwicklung
    • devel_kde: KDE-Entwicklung
    • devel_mono: .NET-Entwicklungt
    • devel_perl: Perl-Entwicklung
    • devel_python: Python-Entwicklung
    • devel_qt4: Qt4-Entwicklung
    • devel_rails: Rails-Entwicklung
    • devel_rpm_build: RPM-Paketbauumgebung
    • devel_ruby: Ruby-on-Rails-Entwicklung (nicht auf den CDs)
    • devel_web: Web-Entwicklung
    • devel_yast: YaST-Entwicklung

Hierbei fehlen einige Selektionen und neue werden eingeführt. Es handelt sich hierbei wirklich erst mal um einen ersten Schritt zu einer Diskussion. Ich würde mich freuen, wenn auch noch andere weitergehende Vorschläge machen!

Let's not discuss "we need this pattern as well" - but let's discuss and agree on the general framework and then let's discuss adding further patterns.

Btw. we have a nice way of adding new, third-party patterns: Basically all you need is to have a lightweight add-on product that only has patterns, but no RPMs. So one could create his or her favourite package collections and make them available as an add-on source. Every repository can add patterns.

Schemata beschreiben

Zur Zeit werden Schemata über .pat-Dateien beschrieben. Allerdings ist das zur Zeit eigentlich eine Implementation für Paketdepots im YaST-Stil und nicht für andere Depottypen wie bspw. repomd-Depots geeignet. Idealerweise sollte eine Schemabeschreibungssprache benutzt werden, die

  • einfach zu schreiben ist.
  • einfach zu lesen ist.
  • einfach zu verarbeiten ist.

Schauen Sie sich dazu den Vorschlag einer Beschreibungsdefinition an.

Inhalt der Schemata

Die oben angestoßene Diskussion über Paketschemata in openSUSE 10.2 geht den Weg von Oben nach Unten, ohne überhaupt auf Pakete einzugehen. Auf der Seite über die Schematainhalte wird der umgekehrte Weg gegangen, indem darüber diskutiert wird, wie sich Pakete zu Schemata gruppieren lassen.

Siehe auch