Re: [gentoo-user-de] USE="doc" ohne 100MB TeX?

[Werner Jansen]

On Tue, 26 Dec 2006 13:52:19 +0100 (CET)
Vaeth <vaeth@××××××××××××××××××××××××.de> wrote:

>
> > Warum zum
> > Henker sollte ich auf meinem LDAP-Server LaTeX installieren? An
> > sich sehe ich hierfür keine Notwendigkeit.
>
> Und warum solltest Du dort gerade eine große Dokumentation
> installieren? Dafür ist Platz aber für LaTeX nicht?

Ja, weil mir die Dokumentation beim Betrieb des Servers hilft,
insofern der Platz sinnvoll investiert ist, der Nutzen ist es wert.
Darüberhinaus gehe ich davon aus, daß die Dokumentation in fast allen
Fällen wesentlich weniger Platz benötigt (sowohl binär als auch als
Source) als LaTeX (inkl Schriften usw usw).

>
> > > Und das, *obwohl* mit gcc - im Gegensatz zu LaTeX - nur
> > > Entwickler/Programmierer etwas anfangen können (außer zur
> > > Installation).
> >
> > [...] Insofern kann mit GCC jeder "etwas anfangen", wenn
> > ihn auch kaum jemand selbst aufruft. Ich glaube, ich habe in
> > meinem Leben noch nie einen gcc manuell gestartet (wenn man
> > make-Aufrufe nicht mitzählt), trotzdem würde ich seine
> > Notwendigkeit für ein Gentoo-System nicht in Frage stellen.
>
> Und genausowenig musst Du LaTeX zum Installieren der Dokumentation
> manuell starten. Wo war noch gleich der Unterschied?

Daß Du nicht verstehst, was ich meine, darin liegt der Unterschied.
Gerade noch hast Du behauptet, jeder will LaTeX, weil jeder seine
Dokumente damit schreibt, jetzt wiederum sagst Du, daß man es ja
nicht starten muß, wenn man nicht möchte. Was denn nun?
GCC gehört de facto nunmal zu Gentoo wie der Pinguin zu Linux. LaTeX
nicht zwangsweise, da nicht extrem viel Dokumentation mit TeX
geschrieben ist. Daher halte ich LaTeX nicht für notwendig, GCC aber
schon. Gib mir ein LaTeX, das maximal 15MB groß ist und mir meine
Dokumentation erstellt, und es ist in Ordnung. Hunderte von MB für
verschiedene Dokumentencompiler zu installieren, sehe ich jedoch
nicht wirklich ein. Wie bereits geschrieben, demnächst kommt einer
auf die (durchaus naheliegende) Idee, seine Dokumentation mit
OpenOffice zu schreiben. Muß ich das dann auf einer Servermaschine
installieren, nur um die Dokumentation der Software lesen zu können?
Das ist ja fast so dämlich wie unter Windows, wo ich Mailing APIs und
Excel-Dateien m.W. aus eigener Software nur dann verwenden kann, wenn
ich Office bzw. Outlook & Excel installiert habe. 

> > > Erstens kann der "Binärcode" (also z.B. das erzeugte PDF)
> > > durchaus von Features der LaTeX-Version und/oder des Viewers
> > > abhängen, die Dokumenatation könnte sogar indirekt von
> > > USE-Flags abhängen (etwa dass Pfade in der Doku angepasst
> > > werden oder dass nicht unterstützte Features auch nicht
> > > dokumentiert werden) (auch wenn beides wohl nicht die Regel
> > > ist),
> >
> > Das halte ich persönlich und aufgrund meiner Erfahrung in größeren
> > Unternehmen für keine gute Lösung.
>
> Die Entscheidung diesbezüglich trifft aber der Paketautor, daran
> kann man so oder so nichts ändern (wenn man nicht selbst die
> Dokumentation schreibt oder den Autor kontaktiert o.ä.).
> Dass Pfade u.ä. an die lokalen Gegebenheiten angepasst werden, ist
> durchaus üblich (und m.E. auch sinnvoll).

Das wäre mir neu. In welcher Dokumentation, die ich mit dem USE-Flag
"doc" aktivieren kann, wird das genau so gemacht?

>
> > Wenn das Dokument immer das gleiche ist, fällt die Versionierung
> > wesentlich leichter.
>
> Versioniert werden die Sourcen, und die können aber eben
> verschiedene Binaries erzeugen.

Wenn ich aber hier eine Mail in die Liste schreibe, daß ich ein
Problem mit der Software XY habe, sie aber "laut Handbuch"
eingerichtet habe, wird die Unterhaltung sich nicht um die Sourcen
der Dokumentation, sondern um die Dokumentation selbst (bzw. das
compilierte Ergebnis) drehen. Daher meine Aussage, daß die
Dokumentation als solches in der gleichen Version konsistent sein
muß, damit alle vom gleichen reden. "Auf Seite x im Kapitel y stand,
daß ...". So etwas funktioniert nur, wenn die Seiten und Kapitel
gleich sind. Daher meine Meinung über homogene Dokumentation.

>
> > Auch wenn
> > man sich über das Dokument oder Teilen davon unterhält,
> > funktioniert das nur, wenn jeder Beteiligte vom selben Dokument
> > spricht.
>
> i.D.R. spricht man nicht über das Dokument, sondern über die
> Sachfragen, die darin geklärt werden. Wenn die Kommunikationspartner
> nicht exakt das selbe System benutzen (in dem Fall haben sie
> natürlich ohnehin die identische Dokumentation), gibt es ohnehin
> immer wieder Unterschiede in der Dokumentation.

Bei der Beantwortung von Sachfragen wird aber immer wieder auf die
Informationsquelle verwiesen. Wie soll Zitieren funktionieren, wenn
es keine einheitliche Repräsentation der Dokumentation gibt?

> > Jedoch halte ich es für ein Gerücht, daß man
> > Binärdaten nicht gut patchen kann. Meistens werden die Dateien
> > ausgetauscht, CVS kann keine diffs für Binärdaten erstellen, das
> > stimmt. Aber das ist nicht ein Problem der Binärdateien, sondern
> > eines der Tools. :)
>
> Ein solches Tool kann es aber prinzipiell nicht geben.

Öhm, warum sollte es ein solches Tool nicht geben können? Beim
Patchen geht es darum, ein paar Bytes durch andere auszutauschen.
Wird die Datei dadurch länger und es verschieben sich im Falle von
Binärdateien Adressen o.ä., müssen entsprechend mehrere Stellen
angepaßt werden können. Die Frage ist hier nur, wo das Tool zum
Patchen ansetzt: Im reinen Datenstrom der Datei oder in der
Repräsentation der Daten (z.B. Zellen in einem Sheet). Ersteres ist
trivial, bei zweiterem muß das Patch-Utility die Semantik der Datei
kennen. Was das textbasierte Tool ja mehr oder weniger auch tut (es
kennt z.B. "Zeilen", es weiß, daß es sich um Text handelt, usw).

> Ich dachte beim Patchen von Dokumentation an so Sachen wie
> "An diesem Rechner ist noch zusätzlich die Option -x hineingepatcht
> worden, die bewirkt, dass ..."
> der eingefügte Absatz kann eine vollkommen andere Formatierung von
> anderen Seiten nach sich ziehen (ev. mit verschobenen
> Tabellen/Bildern, die dann ebenfalls anders platziert werden
> müssen), was man ohne Kenntnis des "geplanten" Layouts (sprich: der
> latex-sourcen) nicht automatisch nur am PDF alleine verändern kann.

Warum nicht? Generier Dir ein PDF ohne die Änderung, generier Dir
eins mit der Änderung und laß Dir (mit einem geeigneten Tool) ein
Binärdiff erstellen. Wo ist das Problem?

Gentoo versucht, sich so nah wie möglich an den offiziellen Quellen
zu halten. Wenn es Binärpakete für Dokumentation geben würde, könnten
die 
 - ausschließlich die offiziellen Inhalte besitzen
 - die spezifischen mit integriert haben, solange sie unabhängig von
der Plattform sind.
 - eigene PDFs (als Beispiel) generieren mit den Änderungen.

usw. Möglichkeiten gäbe es genug.

>
> > Ich wiederhole mich nur ungern, aber wir reden schon von Gentoo?
> > Sorry Bernd, für die ausgeliehene Floskel :)
> > Gentoo _lebt_ davon, daß man sich die benötigten Softwarepakete
> > aus den Weiten des Internets herunterlädt.
>
> Die *Source*-Pakete, nicht die *Binär*-Pakete.

Ach? Opera ist also ein Source-Paket? VMWare ist auch eines? Wie
sieht es aus mit den TrueType-Schriften? Wie Du siehst, es müssen
nicht zwangsweise Quellpakete sein, die heruntergeladen werden. Warum
also sich darauf beschränken? Portage ist so flexibel, daß es nicht
vorschreibt, was mit den heruntergeladenen Dateien passieren muß. Was
spricht also dagegen, diese Flexibilität zu nutzen? 

> > Natürlich ist Bandbreite begrenzt, natürlich ist es keine
> > unendlich vorhandene Ressource.
> > Aber die 2-3MB Dokumentation machen es bei Gentoo nun wirklich
> > nicht aus.
>
> Pro größerem Paket und *bei jedem Versionsupdate jedes Pakets
> erneut*.

Wenn der Nutzer das USE-Flag aktiviert hat, ja. Ansonsten nein. Aber
das kann ja jeder für sich selbst
entscheiden. /etc/portage/package.use existiert und funktioniert.

> > 1. diese (laut aktuellem Stand der Unterhaltung von Bernd und
> > mir) nur heruntergeladen würde, wenn das "doc" USE-Flag gesetzt
> > ist oder die Doku explizit "emerged" wird. M.a.W. es kann sich
> > jeder selbst aussuchen, ob er das Doku-Paket möchte oder nicht.
>
> Aber der häufigste Fall für den Normalbenutzer ist:
> Die Dokumenatation möchte er (installiert) haben, dazu aber
> nicht ein riesiges Binärpaket ziehen, das der Rechner automatisch
> aus den bereits ohnehin vorhandenen Sourcen erstellen könnte.

Warum stellst Du an dieser Stelle wieder Annahmen auf, die so nicht
stimmen (können)? Wenn dem so wäre, wäre das "doc" USE-Flag per
default aktiviert. Ist es aber nicht. 
Meine Vermutung wäre daher, daß das Gros der Nutzer _keine_
"erweiterte Dokumentation" (wie durch "doc" erzeugt) auf ihrem
Rechner hat.
Ich für meinen Teil hatte es noch nie global aktiviert, sondern nur
für ausgewählte Packages, von denen ich die Doku haben wollte. Sieh
Dir einmal an, was sich auf Deinem System befindet, wenn Du ein Paket
installiert hast: die Man pages, ein paar Info-Dateien und Dinge wie
"README" usw. im /usr/share/habsvergessen. 

Vielleicht sollten wir klären, was ich mit Dokumentation meine. Es
geht mir nicht um die o.g. Dinge, die ohnehin auf dem System landen.
Es geht mir um die "erweiterte" Dokumentation, über deren Existenz
ich über das USE-Flag "doc" entscheiden kann. Entweder global (wer
macht denn sowas?) oder für ausgewählte Pakete. 

>
> > 2. Kann ich wirklich viele, viele, viele, Doku-Pakete
> > herunterladen, bis ich bei den 100MB LaTeX bin, die ich nur als
> > Sekundärabhängigkeit benötige in diesem Zusammenhang.
>
> 10 größere Pakete mit je 5 Updates, schon ist man bei
> "unentschieden".

Richtig. Kerberos-Server: 1 Dokumentation von "mit-krb5", 1
Samba-Server mit "doc" bei Samba aktiviert. 1 DHCP-Server mit "doc"
aktiviert. Macht aus dem Ärmel geschüttelt 3 Dienste, also 3mal
Dokumentation. Auch unter der Annahme, daß DHCP eine repräsentativ
große Dokumentation hat (was ich nicht glaube), kann ich so 3 Pakete
je 16,6mal aktualisieren (um bei Deiner Rechnung mit insges. 50
Updates zu bleiben), bevor ich den einmaligen Download von LaTeX
erreicht habe. Das aber auch nur, wenn das /usr/portage/distfiles/
unter den verschiedenen Servern geteilt wird, also bereits eine
Optimierung stattgefunden hat. Keine besonders günstige Rechnung für
LaTeX. Für Gentoo-Releases ("-rX") muß sich die Abhängigkeit zum
Binärpaket der Dokumentation wohl oft nicht ändern, ähnlich
könnte es für kleinere Versionswechsel (3.2.4 auf 3.2.5 z.B.) sein.
Wenn es nur Bugfixes sind, ändert sich die Dokumentation unter
Umständen gar nicht. Daher wird die obige Rechnung noch weiter zu
Ungunsten von LaTeX verschoben.

>
> > Und ich bedanke mich, wenn ich über 100MB LaTeX dafür ziehen muß,
> > daß mir portage ein paar PDFs oder PS-Dateien erstellen kann, die
> > dann zusammengerechnet grad mal ein paar MB ausmachen.
>
> Dann mach Dir Binary-Pakete und installiere diese - genau dafür sind
> sie gedacht.

Öhm, und wo erstelle ich die Binary-Pakete? Auf einem Rechner, auf
dem LaTeX installiert ist? Dann mußte ich es ja doch herunterladen.
Also nichts gewonnen.

Außerdem bin ich immer noch der Meinung, daß die Dokumentation nur in
einem vernachlässigbar geringen Teil dynamisch angepaßt wird an die
Umgebung. Wenn die Dynamik so stark wäre, wie könnten dann viele
Softwareprojekte ihre Dokumentation in "Binärform" (PDF, PS, HTML)
online zur Verfügung stellen?

>
> > Der "megabyteweise" Download von Dokumentation ist zielgerichtet:
> > Es wird das heruntergeladen, was ich auf meinem System haben will.
>
> ...für die aktuelle Version des Pakets.
> Wenn Du alles nur "zielgerichtet" installieren willst, benutze
> Binary-Pakete.

Natürlich für die aktuelle Version des Pakets, für eine veraltete
bringt mir die Dokumentation nichts und für die noch nicht
erschienene werde ich wohl kaum Dokumentation finden. Was hat
zielgerichtet mit Binarypaketen zu tun?

>
> > Wenn jedoch, um das zu erstellen, was ich haben will, mein System
> > sich derart aufbläht, daß man nicht mehr von einem schlanken
> > System sprechen kann
>
> latex bläht genausosehr oder genausowenig auf wie gcc.
> Wenn Du keine Installationstools auf dem System haben willst,
> benutze Binary-Pakete.

LaTeX ist für mich kein Installationstool, es ist eine umfangreiche,
komplexe, eigene Umgebung, weit entfernt von dem, was ich noch als
"Tool" bezeichnen würde. Für den Zweck, eine meist statische
Dokumentation zu erzeugen, ist es für mich gleich 2mal kein
Installationstool.

>
> > Was kommt dann als nächstes? Muß ich openoffice
> > installieren, um die Doku erzeugen zu können, weil er aus einem
> > OpenOffice-Dokument PDF erzeugen will? Das Ganze auf einem
> > Rechner, wo ich nur (z.B.) DNS, DHCP samt kompletter Doku haben
> > möchte? Diese Reihe läßt sich fortsetzen ...
>
> Das sind gute Gründe für die Benutzung für Binary-Pakete,
> aber kein guter Grund, alle anderen Benutzer zu
> Binary-Paketen/-Dokumentation zu zwingen.

Der einzige, wer hier von zwingen redet, bist Du. Es zwingt doch
niemand einen, dieses USE-Flag (dessen Existenz ich jetzt
unterstelle), das Binärdokumentation installiert, deaktiviert zu
lassen. Wenn ichs nicht will, dann nicht. Wenns jemand will, kann ers
tun. Wenn er Binary-Pakete auch für die Software will, kann er die
installieren, wenn er die Software compilieren, aber die Doku als
Binärpaket haben will, um sich nicht LaTeX, SGML-Tools, FileMaker,
OpenOffice und was weiß ich nicht noch alles auf den Rechner
installieren zu müssen, dann könnte er das auch tun. Warum lehnst
Du es so kategorisch ab, nur weil Du es nicht brauchen kannst?

>
> > > Was man ohne Portage-Änderung machen könnte, wäre
> > > möglicherweise ein Auslagern der LaTeX-Dokumentation in eigene
> > > Pakete, die man dann entweder "normal" (also mit LaTeX)
> > > installieren kann oder halt von einem Binärserver als
> > > Binärpakete (mit emerge -k o.ä.) installieren kann.
> >
> > Oder siehe meine letzte Mail: Die Quellen bleiben so, wie sie
> > sind. Eine Aktivierung eines "doc"-USE-Flags (oder ein
> > "doc-binary") erzeugt eine Abhängigkeit zum Doku-Paket, in dem die
> > Dokumentation im Binärformat enthalten ist.
>
> Der Unterschied ist, dass man mit dem "doc"-USE-Flag bisher
> die Dokumentation aus den Sourcen bekam (soweit vorhanden),
> man nach Deinem Vorschlag aber zusätzliche Daten herunterladen muss.

Muß man nicht. Nur wenn das USE-Flag aktiviert ist. Dann ist davon
auszugehen, daß dieser Download gewünscht ist. Und zusätzliche Dateien
muß ich auch herunterladen, wenn ich LaTeX nicht installiert habe. Da
hier bereits feststeht, daß dieser Vergleich ungünstig für LaTeX
ausgeht (1. größerer Download, 2. mehr Zeit zum Compilieren), kann das
Argument also nicht auf den Download aus sein. Worauf willst Du
hinaus?

> Wenn Du *zusätzlich* zu dem doc-Useflags auch ein doc-binary-Useflag
> einführen willst, habe ich nichts dagegen.

<sarkasmus>
Das ist aber nett, daß ich da von Dir die Genehmigung bekäme. Hab ich
das nicht bereits geschrieben, daß ich mir ein "bindoc"-Flag
vorstellen könnte?
</sarkasmus>

> Ob dieser enorme zusätzliche Aufwand aber von
> den .ebuild-Maintainern begeistert aufgenommen würde, wage ich zu
> bezweifeln...

Um Dich zum wiederholten Male auf etwas hinzuweisen: Es würde (wenns
nach meinem Vorschlag ginge) weder der Benutzer noch der Maintainer
gezwungen, diese Pakete a) zu erstellen oder b) zu nutzen. Ich
persönlich sähe einen Gewinn in dieser Vorgehensweise und wollte
diese zur Diskussion stellen. 
Unter "Diskussion" verstehe ich, sich konstruktiv über Vor- und
Nachteile der Sache auszutauschen (siehe Mail-Austausch mit Bernd,
den ich als Diskussionspartner schätze), nicht
aber, unhaltbaren Behauptungen "Jeder will LaTeX auf seinem Computer
haben!" erst einmal mühsam den Bezug zur Sache entnehmen zu müssen.

Noch einmal ganz langsam:

1. Es geht nicht nur um den verschwendeten Platz.
2. Ein Server braucht nunmal kein LaTeX (in den meisten Fällen).
3. Ich halte meine Server gerne schlank, darum laufen sie ja unter
Gentoo. Nur wirklich benötigte und aktivierte Abhängigkeiten sind
installiert. LaTeX mit seinen Abhängigkeiten fällt bei einem
schlanken System prozentual durchaus ins Gewicht. Und wozu? Um eine
Dokumentation zu generieren, die sich in den meisten Fällen zwischen
den Systemen/Plattformen nicht unterscheidet. Wo ist hier der Vorteil
des "selbstcompilierens"? Ich sehe keinen.

Daher hatte ich die Idee, eine bereits erzeugte Doku als eigenes
Paket anzubieten. Und damit der Nutzer diese Pakete nicht eigens
suchen muß, bei Aktivierung eines USE-Flags (das von mir aus auch
"Steckerlfisch" heißen kann) die Binärdoku als Abhängigkeit geladen
und installiert wird. 

> > Das Paket auf einem anderen Rechner (z.B. Desktop-Rechner) mit
> > "doc" emergen und dort lesen, wo LaTeX ohnehin installiert ist?
> > (halte ich für häßlich, die ganzen Pakete irgendwo rumliegen zu
> > haben)
>
> Wieso "rumliegen haben"?
> Auf dem "Mutterrechner" (der zum Kompilieren geeignet ist -
> wenn man keinen solchen hat, ist vermutlich ohnehin eine
> Binärdistribution besser geeignet)
> hat man ein sh-Skript, das ein geeignetes USE exportiert und dann
>    exec emerge -1B "${@}"
> ausführt. Auf dem Laptop (oder Server mit knappem Plattenplatz -
> gibt es so etwas bei einem Server wirklich?) hat man ohnehin schon
>    EMERGE_DEFAULT_OPTS="-k"
> gesetzt und installiert dann das Binary-Paket.

Ich weiß nicht, was Du für Klimmzüge machst, aber meine Server
compilieren ihre Software meistens selbst. Manchmal auch gemeinsam
(distcc). Da sie immer wieder unterschiedlich in den Anforderungen
sind, unterscheiden sich USE-Flags und CFLAGS (mindestens) nicht
unwesentlich, daher erstelle ich Binärpakete nur zum "Rollback" nach
einem evtl. fehlgeschlagenem Update. Wenn ich das nicht wollte, könnte
ich auch eine Binärdistribution hernehmen, die mir hunderte von
Paketen als Pseudoabhängigkeit installiert, bloß weil das Binärpaket
gegen alles mögliche gelinkt ist. Genau das vermeide ich mit Gentoo. 

Insofern stimmt Deine Annahme, daß "man ein sh-Skript [hat], das
ein geeignetes USE exportiert ..." nicht. Wozu soll
ein "Mutterrechner" gut sein? Weder meine Kunden noch ich haben
einen leistungsstarken Server übrig, den man für
Systemupdate-Aufgaben abstellen kann bzw. will.
Das, was Du machst, hört sich für mich nach einer im universitären
Umfeld typischen Lösung an. Vor allem in der Physik und
Mathematik. :)
Nicht alle machen es so wie Du. Was die anderen Lösungen weder als
besser noch als schlechter klassifiziert. Das ist das schöne an
Gentoo ...

Viele Grüße,

Werner

-- 
gentoo-user-de@g.o mailing list