Paketbaurichtlinien für Web Assets

Web-Assets sind statische Inhalte, die unverändert an Webbrowser ausgeliefert werden, üblicherweise von Webanwendungen. Dabei kann es sich um Frameworks für Benutzeroberflächen, Flash-Videoplayer, CSS-Frameworks, Symbolbibliotheken oder viele andere Möglichkeiten handeln.

Wenn Ihr Paket hauptsächlich oder ausschließlich an einen Browser gesendet und nicht lokal verwendet wird und kein JavaScript ist, fällt es wahrscheinlich unter diese Richtlinien. JavaScript-Pakete müssen zusätzlich zu diesen Richtlinien auch die JavaScript-Richtlinien befolgen.

Es gibt viele kleine Komponenten, die an Browser ausgeliefert werden und nicht nur JavaScript enthalten, das bisher üblicherweise mit Webanwendungen gebündelt wurde. Es gibt viele gute Gründe, warum wir JavaScript _nicht auf diese Weise bündeln sollten. Daher sollten wir dies auch für die übrigen Komponenten dieser Art ändern.

Um das Vorhandensein der notwendigen RPM-Makros sicherzustellen, müssen alle Pakete, die Web-Assets bereitstellen, Folgendes enthalten:

Um die Verfügbarkeit der erforderlichen Verzeichnisse zu gewährleisten, müssen alle Pakete, die Web-Assets bereitstellen, Folgendes enthalten:

Webanwendungspakete, die Konfigurationsdateien für Apache HTTPd mitliefern, sollten sicherstellen, dass die httpd-Konfiguration ebenfalls installiert ist:

Alle Pakete mit statischen Inhalten für verschiedene Webanwendungen müssen in einem Unterverzeichnis von %{_assetdir} installiert werden. Beispielsweise sollte sich das Paket jquery-ui in %{_webassetdir}/jquery-ui installieren.

Alle Pakete mit statischen Inhalten, die nur innerhalb des jeweiligen Pakets, in dem sie ausgeliefert werden, nützlich sind, sollten diese Inhalte weiterhin in der Verzeichnisstruktur der Anwendung enthalten. Sie müssen jedoch die übrigen in diesem Dokument beschriebenen Richtlinien befolgen.

Alle HTTP-Daemons in der Distribution sollten %{_webassetdir} in /.sysassets verfügbar machen.

Wenn das Paket fabulous-web-icons also ein Symbol unter dem Pfad %{_webassetdir}/fabulous-web-icons/important.png bereitstellt, können Sie es mit folgendem HTML-Code in eine Webanwendung einbinden:

Ungeachtet dessen kann es für Webanwendungen sinnvoll sein, Unterverzeichnisse von %{_webassetdir} aus Kompatibilitätsgründen oder zur Vermeidung unnötiger Abweichungen vom Upstream-Verzeichnis über Aliase oder symbolische Links in ihrem eigenen Verzeichnis verfügbar zu machen.

Web-Assets müssen den allgemeinen Richtlinien für was paketiert werden kann entsprechen, sofern in diesem Dokument nichts anderes angegeben ist.

Reine CSS-Frameworks können unverändert eingebunden werden. CSS-Frameworks, die eine alternative Sprache verwenden, die zu CSS kompiliert wird, wie beispielsweise LESS, müssen im Rahmen des Bauprozesses zu CSS kompiliert werden.

Pakete, die CSS enthalten, sollten nach Möglichkeit vorkompiliertes/minimiertes CSS neu generieren, da dies zu besser wartbaren Paketen führt. Falls dies mit erheblichem Aufwand verbunden ist, kann das gebündelte, vorgenerierte CSS mit einem Kommentar in der Spec-Datei versehen werden, der die Entscheidung erläutert. Die Überprüfung der Lizenzen der gebündelten Inhalte bleibt davon unberührt.

Flash-Dateien (die typischerweise die Dateiendung .swf verwenden) müssen den allgemeinen und lizenzrechtlichen Richtlinien für Code, nicht für Inhalte, entsprechen und müssen aus dem Quellcode mit einer in Fedora verfügbaren Toolchain erstellt werden.

Die Flash-Software muss mit einer freien Software-Toolchain wie swfc kompiliert werden. Vorkompilierte .swf-Dateien dürfen nicht in Fedora-Pakete aufgenommen werden. Diese Kompilierung muss im Rahmen des Paketierungsprozesses erfolgen.

Lässt sich die Flash-Software mit den in Fedora integrierten Toolchains nicht kompilieren, kann sie nicht ausgeliefert werden. In manchen Fällen lässt sich die Verwendung der Flash-Software möglicherweise umgehen (z.B. wenn sie als Fallback dient, falls der Browser HTML5 nicht unterstützt). Andernfalls muss die Paketierung der Software vorerst ausgesetzt werden, bis die Flash-Software-Toolchain so erweitert wurde, dass sie kompiliert werden kann.

Java-Applets sollten den allgemeinen und den Lizenzierungsrichtlinien für Code, nicht aber für Inhalte, entsprechen. Zusätzlich sollten sie den Java-Richtlinien folgen, mit der Ausnahme, dass die eigentliche .jar-Datei des Java-Applets in einem Unterverzeichnis von %{_webassetdir} installiert werden sollte.

Bilder, die Teil eines größeren Web-Asset-Pakets sind, können im Unterverzeichnis dieses Pakets abgelegt werden. Beispielsweise könnte eine UI-Bibliothek Bilder für ihre UI-Komponenten in ihrem Unterverzeichnis enthalten.

Web-Asset-Pakete, die ausschließlich aus Bildern bestehen, wie beispielsweise ein Satz von Symbolen, können als eigenes Paket ausgeliefert werden.

Alle Systemschriftarten (verfügbar in %{_datadir}/fonts) werden automatisch über einen symbolischen Link in %{_webassetdir}/fonts/ bereitgestellt. Weitere Informationen zum Paketieren von Systemschriftarten finden Sie in den Richtlinien für Schriften. Bitte beachten Sie, dass standardmäßig nur Schriftarten aus der Fedora-Paketsammlung auf HTTP-Servern verfügbar sind.

Bitte beachten Sie, dass diese Richtlinien das Paketieren von Schriftarten an anderer Stelle untersagen. Es gibt keinen zwingenden Grund, andere Schriftformate zu unterstützen, da die meisten Browser, die Webfonts unterstützen, die von Systemfonts verwendeten TTF- oder OTF-Formate unterstützen. Daher sind alternative Webfont-Formate wie WOFF nicht zulässig.