6
2

Von manchen Paketen gibt es neben den offiziellen und als stabil bezeichneten Versionen auf CTAN auch andere Bezugsquellen, die teilweise neuere aber nicht ausdrücklich als stabil gekennzeichnete Versionen bereitstellen. Bei vielen Paketen gibt es inzwischen auch öffentlich zugängliche Repositories, aus denen man den aktuellen Entwicklerstand herunterladen kann oder auch sogenannte daily snapshots. Kann man diese einfach an Stelle der Version von CTAN verwenden oder sollte man das vielleicht sogar?

gefragt 26 Aug '13, 03:24

saputello's gravatar image

saputello
18.4k22352
Akzeptiert: 89%

bearbeitet 08 Mai '14, 03:13

Bes's gravatar image

Bes
1411516

Was soll in diesem Beitrag der Zusatz "offiziell" besagen? Tex bietet die Möglichkeit, Makros zu definieren, Latex ist die resultierende Makrosprache. Makros sind per Definition zusammengefasste Kommandos, http://de.wikipedia.org/wiki/Makro , die der Anwender nach Belieben und nach Situation definieren und anwenden kann. Es gibt keine "amtliche" Stelle, die solche Makros bewerten oder freigeben oder verbieten kann und es ist zu hoffen, daß es eine solche "amtliche" Stelle niemals geben wird.

(07 Mai '14, 20:11) ctansearch
3

@ctansearch Ich denke, dass hier offizielle, stabile Version im Gegensatz zu Entwicklerversion, Testversion o. ä. gemeint ist. So geht es jedenfalls für mich aus dem zweiten Satz hervor. Da die Pakete auf CTAN normalerweise von den Maintainern selbst freigegeben sind, kann man CTAN-Veröffentlichungen durchaus so verstehen. Das bedeutet nicht, dass es solche Versionen nicht auch an anderer Stelle geben kann.

Offiziell also nicht als amtlich, sondern als vom Verantwortlichen formell zur allgemeinen Benutzung und zur Benutzung und Weiterverbreitung freigegeben.

Richtig, @saputello?

(08 Mai '14, 03:10) Bes

@Bes so hab ich's auch verstanden

(08 Mai '14, 05:23) Clemens

@Bes OK, alles klar.

(08 Mai '14, 16:15) ctansearch

Diese Frage ist nicht ganz leicht zu beantworten, da dabei verschiedene Aspekte eine Rolle spielen. Da ist zum einen die Frage der Installation, zum anderen die Frage der Verwendung.

Typen von nicht stabilen Versionen:

Zunächst ist zwischen daily snapshots, Repository-Versionen und Beta-Versionen zu unterscheiden.

Im Repository (beispielsweise CVS, Subversion, Git u. v. m.) ist in der Regel der brand-aktuelle Entwicklungsstand (aka trunk) zu finden. In der Regel gibt es keinerlei Informationen darüber, inwieweit dieser getestet ist. In Einzelfällen kann es sogar sein, dass man aus dem dort befindlichen Quelltext wegen eines Fehlers gar keine funktionierenden Pakete erzeugen kann. Teilweise findet man aber auch stabilere Entwicklungszweige (aka branches), die gesondert gekennzeichnet sind. Sie alle werden im Folgenden als Entwicklerversionen bezeichnet.

Daily Snapshots werden in der Regel vollautomatisch aus dem Repository erzeugt. Damit fallen sie ebenfalls in die Kategorie Enwicklerversionen.

Beta-Versionen sind hingegen spezielle von den Entwicklern freigegebene Versionen, die meist gewisse Mindesttests erfolgreich bestritten haben und deren Anwenderschnittstelle zwar nicht unveränderlich ist, aber durchaus in dieser Form für zukünftige stabile Versionen geplant ist. Zu Testzwecken ist die Verwendung ausdrücklich erwünscht.

Folgen der Installation und Verwendung nicht stabile Versionen

Bezüglich der eigenen LaTeX-Installation ergibt sich durch die Installation von Entwicklerversionen oder Beta-Versionen von Paketen das Problem, dass die Verwaltung aufwändiger wird. Während die Paketversionen, die von der jeweiligen TeX-Distribution bereit gestellt werden, leicht über den Paketmanager der TeX-Distribution verwaltet und aktuell gehalten werden können, muss man bei den manuell zu installierenden Entwicklerversionen zunächst lernen, wie man diese korrekt installiert, und dann jedes einzelne Paket ggf. selbst aktuell halten.

Bezüglich der Verwendung von nicht als stabil gekennzeichneten Versionen ergibt sich das Problem, dass diese in der Regel weder gut getestet sind, noch sichergestellt ist, dass alle Features bei der nächsten Entwicklerversion oder der nächsten stabilen Version noch in gleicher Weise funktionieren. Daher kann es sowohl sein, dass ein existierendes Dokument mit der Entwicklerversion nicht mehr funktioniert, als auch, dass ein mit der Entwicklerversion neu erstelltes Dokument mit der nächsten Version nicht mehr funktioniert. Darüber hinaus kann es auch sein, dass andere Pakete, die mit diesem Paket zusammenarbeiten (müssen) noch nicht mit der aktuellen Entwicklerversion zusammenarbeiten, bzw. für diese anderen Pakete dann ebenfalls Entwicklerversionen notwendig sind. Dieses Problem kann sich aufschaukeln.

Auf der anderen Seite ist es so, dass Entwickler meist froh sind, wenn ihre öffentlich zugänglichen Entwicklerversionen möglichst früh von möglichst vielen Menschen getestet werden. Nur so kann sichergestellt werden, dass möglichst viele Fehler und Designschwächen frühzeitig erkannt werden.

Manchmal ist man zur Lösung für ein Problem, sei es aufgrund eines Fehlers in einem Paket oder schlicht aufgrund eines neuen Features in der Entwicklerversion, auch auf eine Entwicklerversion angewiesen. Dann bleibt einem kaum eine Wahl, trotzdem sollte man sich über die Risiken und Nachteile im Klaren sein.

In der Regel ist es also empfehlenswert für den produktiven Einsatz möglichst nur stabile Versionen und in erster Linie die vom Paketmanager der jeweiligen TeX-Distribution bereitgestellte Versionen von Paketen zu verwenden. Für den temporären Einsatz von Entwicklerversionen bietet es sich an, einen eigenen TEXMF-Baum (aka TDS-Baum) anzulegen.

Möglichkeiten zur Verwendung einer nicht stabilen Version

Bei MiKTeX geht das Anlegen eines weiteren TEXMF-Baums für Entwicklerversionen einfach über die Einstellungen. Das geht so einfach, dass man sogar für jedes Entwicklerpaket einen eigenen TEXMF-Baum anlegen kann. Diesen kann man dann nach Bedarf aktivieren und deaktivieren.

Bei TeX-Live bietet sich theoretisch der private TEXMF-Baum für Entwicklerversionen von Paketen an. Allerdings ist das nur dann wirklich sinnvoll, wenn man für Tests einen eigenen Benutzer hat. Anderenfalls ist es besser, einen neuen TEXMF-Baum anzulegen und diesen beispielsweise über das lokale Setzen der Umgebungsvariablen TEXMF zu aktivieren. Linux-Anwender könnten dazu beispielsweise ein Script wie

    #!/bin/sh
    TEXMF="$HOME/texmf-beta//:$( kpsewhich -var-value=TEXMF )"
    export TEXMF
    pdflatex "$@"
anlegen und dieses an Stelle von pdflatex aufrufen. Dieses erweitert den Suchpfad um die Komponente $HOME/texmf-beta, also einen TEXMF-Baum namens texmf-beta im Benutzerverzeichnis, wobei dieser TEXMF-Baum ggf. komplett durchsucht wird. Es ist also nicht notwendig, dafür texhash aufzurufen.

Statt in der letzten Zeile pdflatex aufzurufen, kann man dort auch den bevorzugten LaTeX-Editor aufrufen. Dann arbeitet dieser und alle von ihm gestarteten Programme mit dem erweiterten TEXMF, also auch pdflatex, makeindex, bibtex oder biber.

Benötigt man eine Entwicklerversion ausschließlich für ein einzelnes Dokument, so gibt es außerdem die Möglichkeit, die Paketdateien der Entwicklerversion im entsprechenden Dokumentverzeichnis abzulegen. Dort werden die Paketdateien in der Regel als erstes gesucht und gefunden. In diesem Fall entfällt auch die aufwändige Verwaltung bezüglich zukünftiger, neuerer Versionen, da die Entwicklerversion ja genau die Version ist, die für dieses Dokument relevant ist. Allerdings muss man dann bezüglich der Weitergabe des Dokumentquelltextes darauf achten, dass die Lizenzbedingungen des Pakets, das zusammen mit dem tatsächlichen Dokumentquelltext weitergegeben wird, eingehalten sind.

Permanenter link

beantwortet 26 Aug '13, 03:52

saputello's gravatar image

saputello
18.4k22352

bearbeitet 15 Jul '15, 06:58

Deine Antwort auf die Frage (nicht auf andere Antworten)
Knebel-Vorschau

Folge dieser Frage

Per E-Mail:

Wenn Du Dich anmeldest, kannst Du Updates hier abonnieren

Per RSS:

Antworten

Antworten und Kommentare

Aktuelle Buch-Infos

LaTeX Cookbook

LaTeX Beginners Guide

Limitierter Rabatt ebook
50% Coupon code tDRet6Y

Markdown-Grundlagen

  • *kursiv* oder _kursiv_
  • **Fett** oder __Fett__
  • Link:[Text](http://url.com/ "Titel")
  • Bild?![alt Text](/path/img.jpg "Titel")
  • nummerierte Liste: 1. Foo 2. Bar
  • zum Hinzufügen ein Zeilenumbruchs füge einfach zwei Leerzeichen an die Stelle ein, an der die neue Zeile sein soll.
  • grundlegende HTML-Tags werden ebenfalls unterstützt

Zugeordnete Themen:

×108
×40
×35
×32

Frage gestellt: 26 Aug '13, 03:24

Frage wurde angeschaut: 3,709 Mal

Zuletzt aktualisiert: 15 Jul '15, 06:58