1 |
> > > [...] Insofern kann mit GCC jeder "etwas anfangen", wenn |
2 |
> > > ihn auch kaum jemand selbst aufruft. [...] |
3 |
> > |
4 |
> > Und genausowenig musst Du LaTeX zum Installieren der Dokumentation |
5 |
> > manuell starten. Wo war noch gleich der Unterschied? |
6 |
> |
7 |
> Daß Du nicht verstehst, was ich meine, darin liegt der Unterschied. |
8 |
> Gerade noch hast Du behauptet, jeder will LaTeX, weil jeder seine |
9 |
> Dokumente damit schreibt, jetzt wiederum sagst Du, daß man es ja |
10 |
> nicht starten muß, wenn man nicht möchte. Was denn nun? |
11 |
|
12 |
Dein Argument - das ich wirklich nicht verstehe - war, dass man |
13 |
den gcc haben "darf", weil man ihn nicht direkt aufrufen muss(?) |
14 |
latex (aus diesem Grund?) aber nicht unbedingt. |
15 |
Zumindest *was Installieren von Paketen betrifft* sehe ich zwischen |
16 |
gcc und latex aber wirklich keinerlei Unterschied. |
17 |
Dass gcc und latex beide natürlich auch anders eingesetzt werden |
18 |
können, ist eine andere Oper. |
19 |
|
20 |
> GCC gehört de facto nunmal zu Gentoo wie der Pinguin zu Linux. LaTeX |
21 |
> nicht zwangsweise, da nicht extrem viel Dokumentation mit TeX |
22 |
> geschrieben ist. |
23 |
|
24 |
Das selbe Argument kannst Du gegen jede andere Programmiersprache |
25 |
anführen: "Man braucht Sprache xxx nicht, weil nicht besonders viel |
26 |
darin geschrieben ist." |
27 |
Trotzdem wird jeder es als normal betrachten, dass unter Gentoo zum |
28 |
Installieren eines Programms dieser Sprache der zugehörige Compiler |
29 |
vorhanden sein muss. |
30 |
|
31 |
> Gib mir ein LaTeX, das maximal 15MB groß ist und mir meine |
32 |
> Dokumentation erstellt, und es ist in Ordnung. |
33 |
|
34 |
Zeig mir das 15 MB große Java (das ich auch nicht will, aber |
35 |
wegen ein paar Programmen halten muss). |
36 |
|
37 |
> verschiedene Dokumentencompiler zu installieren, sehe ich jedoch |
38 |
> nicht wirklich ein. Wie bereits geschrieben, demnächst kommt einer |
39 |
> auf die (durchaus naheliegende) Idee, seine Dokumentation mit |
40 |
> OpenOffice zu schreiben. Muß ich das dann auf einer Servermaschine |
41 |
> installieren, nur um die Dokumentation der Software lesen zu können? |
42 |
|
43 |
Sinnvollerweise ja. Wobei die Idee, Dokumentation in einem proprietären |
44 |
Format zu erstellen, hoffentlich für keinen OpenSource-Entwickler |
45 |
naheliegend ist. |
46 |
|
47 |
> > Dass Pfade u.ä. an die lokalen Gegebenheiten angepasst werden, ist |
48 |
> > durchaus üblich (und m.E. auch sinnvoll). |
49 |
> |
50 |
> Das wäre mir neu. In welcher Dokumentation, die ich mit dem USE-Flag |
51 |
> "doc" aktivieren kann, wird das genau so gemacht? |
52 |
|
53 |
Üblich ist es vor allem bei manpages (bei eix weiß ich es sicher...), |
54 |
ich glaube mich auch zu erinnern, dass Vieles der tetex-Dokumentation |
55 |
(z.B. kpathsea) heftig Gebrauch davon macht. Bei anderen Paketen |
56 |
hatte ich bislang noch keinen Anlass, darauf zu achten... |
57 |
|
58 |
> > > Jedoch halte ich es für ein Gerücht, daß man |
59 |
> > > Binärdaten nicht gut patchen kann. Meistens werden die Dateien |
60 |
> > > ausgetauscht, CVS kann keine diffs für Binärdaten erstellen, das |
61 |
> > > stimmt. Aber das ist nicht ein Problem der Binärdateien, sondern |
62 |
> > > eines der Tools. :) |
63 |
> > |
64 |
> > Ein solches Tool kann es aber prinzipiell nicht geben. |
65 |
> |
66 |
> Öhm, warum sollte es ein solches Tool nicht geben können? Beim |
67 |
> Patchen geht es darum, ein paar Bytes durch andere auszutauschen. |
68 |
> Wird die Datei dadurch länger und es verschieben sich im Falle von |
69 |
> Binärdateien Adressen o.ä. |
70 |
|
71 |
Wir verstehen unter Patchen zwei verschiedene Dinge: |
72 |
Ich meine damit den Vorgang der Veränderung der Datei |
73 |
*nach meinen lokalen Gegebenheiten/Wünschen*, |
74 |
nicht den Vorgang des Verteilens dieser Veränderung mit möglichst |
75 |
wenig Aufwand. Das zweite kann man sicher mit einem binary-diff-Tool |
76 |
erreichen, aber das erste nicht ohne die .tex-Sourcen (im Falle des |
77 |
Patchens von Dokumentation), denn: |
78 |
|
79 |
> muß das Patch-Utility die Semantik der Datei kennen. |
80 |
|
81 |
Diese Semantik steht in der pdf-Datei nicht mehr - die steht nur |
82 |
in den .tex-Sourcen. |
83 |
|
84 |
> Warum nicht? Generier Dir ein PDF ohne die Änderung, generier Dir |
85 |
> eins mit der Änderung und laß Dir (mit einem geeigneten Tool) ein |
86 |
> Binärdiff erstellen. Wo ist das Problem? |
87 |
|
88 |
Anstelle z.B. ein sed-Kommando in ein .ebuild einzufügen, |
89 |
soll ich demnach händisch zunächst die .tex-Sourcen finden und |
90 |
herunterladen, das eigentliche Patchen durchführen, danach das pdf |
91 |
erstellen, die Änderungen mit einem weiteren Tool mit einem weiteren |
92 |
herunterzuladenden pdf vergleichen und kann erst dann das .ebuild |
93 |
patchen? Und das Ganze beim nächsten Versionsupdate wiederholen? |
94 |
Alles andere als praktisch... |
95 |
|
96 |
> Gentoo versucht, sich so nah wie möglich an den offiziellen Quellen |
97 |
> zu halten. Wenn es Binärpakete für Dokumentation geben würde, könnten |
98 |
> die [...] |
99 |
|
100 |
Nun ist es aber so, dass in den Fällen, um die wir diskutieren |
101 |
(die anderen Fälle sind für unsere Diskussion irrelevant), |
102 |
Upstream die Dokumentation nicht als Binärpaket verteilt, sondern |
103 |
als .tex-Sourcen o.ä. mit Makefile. |
104 |
Wo Upstream die Dokumentation anders handhabt (svn fällt mir |
105 |
z.B. ein) macht das Gentoo sowieso anders (im Falle von svn z.B. |
106 |
war dadurch der .ebuild-Maintainer anscheinend sogar zu bequem, |
107 |
überhaupt doc zu unterstützen). |
108 |
|
109 |
> > Die *Source*-Pakete, nicht die *Binär*-Pakete. |
110 |
> |
111 |
> Ach? Opera ist also ein Source-Paket? VMWare ist auch eines? Wie |
112 |
> sieht es aus mit den TrueType-Schriften? |
113 |
|
114 |
Das sind Ausnahmen, in denen Gentoo *gezwungenermaßen* nicht von den |
115 |
Sourcen installieren kann, weil diese nicht frei verfügbar sind. |
116 |
Ich bedaure auch sehr, dass es solche Ausnahmen leider gibt, |
117 |
insbesondere flash, realplayer, acroread, nvidia-driver, ati-driver, ... |
118 |
Gentoo sollte nicht ohne Not zusätzliche solcher Fälle einführen. |
119 |
|
120 |
> > > Aber die 2-3MB Dokumentation machen es bei Gentoo nun wirklich |
121 |
> > > nicht aus. |
122 |
> > |
123 |
> > Pro größerem Paket und *bei jedem Versionsupdate jedes Pakets |
124 |
> > erneut*. |
125 |
> |
126 |
> Wenn der Nutzer das USE-Flag aktiviert hat, ja. Ansonsten nein. Aber |
127 |
> das kann ja jeder für sich selbst |
128 |
> entscheiden. |
129 |
|
130 |
Nach Deinem Vorschlag, die Bedeutung von doc in "Binärdokumentation" |
131 |
umzuändern, hat man die ursprüngliche Möglichkeit (Dokumentation |
132 |
ohne Herunterladen neuer Daten) eben nicht mehr: |
133 |
Das ist das, wogegen ich protestiere. |
134 |
Und leider wird Dein Vorschlag in der Praxis darauf hinauslaufen |
135 |
(dazu später mehr). |
136 |
|
137 |
> > Aber der häufigste Fall für den Normalbenutzer ist: |
138 |
> > Die Dokumenatation möchte er (installiert) haben, dazu aber |
139 |
> > nicht ein riesiges Binärpaket ziehen, das der Rechner automatisch |
140 |
> > aus den bereits ohnehin vorhandenen Sourcen erstellen könnte. |
141 |
> |
142 |
> Warum stellst Du an dieser Stelle wieder Annahmen auf, die so nicht |
143 |
> stimmen (können)? Wenn dem so wäre, wäre das "doc" USE-Flag per |
144 |
> default aktiviert. Ist es aber nicht. |
145 |
|
146 |
Offensichtlich reden wir hier wieder aneinander vorbei: |
147 |
Ich sprach nirgendwo davon, dass User global "doc" aktivieren, |
148 |
sondern ich meine natürlich nur die Pakete, für die die Benutzer |
149 |
"doc" aktiviert haben - die anderen Fälle sind ja für unsere Betrachtung |
150 |
uninteressant. Und ich denke, dass es den meisten Benutzern |
151 |
sehr recht ist, dass sie in diesen Fällen möglichst wenig (oder oft |
152 |
gar keine) zusätzlichen Daten herunterladen müssen. |
153 |
|
154 |
> Vielleicht sollten wir klären, was ich mit Dokumentation meine. Es |
155 |
> geht mir nicht um die o.g. Dinge, die ohnehin auf dem System landen. |
156 |
> Es geht mir um die "erweiterte" Dokumentation, über deren Existenz |
157 |
> ich über das USE-Flag "doc" entscheiden kann. |
158 |
|
159 |
Hier reden wir schon vom selben. Viele Pakete sind ohne diese |
160 |
"erweiterte" Dokumentation nahezu unbenutzbar [außer für externe |
161 |
Programme]. Bei tetex beispielsweise gäbe es dann praktisch gar keine |
162 |
Dokumentation außer der Beschreibung der Kommandozeilenoptionen, bei |
163 |
einigen anderen Paketen - hab jetzt vergessen, welche - gibt es nicht |
164 |
einmal man- oder infopages. Dagegen ist ja auch nichts zu sagen. |
165 |
Aber die Dokumentation dann zusätzlich als binäre PDFs herunterladen |
166 |
zu müssen, würde mir nicht schmecken... |
167 |
|
168 |
> > Dann mach Dir Binary-Pakete und installiere diese - genau dafür sind |
169 |
> > sie gedacht. |
170 |
> |
171 |
> Öhm, und wo erstelle ich die Binary-Pakete? Auf einem Rechner, auf |
172 |
> dem LaTeX installiert ist? Dann mußte ich es ja doch herunterladen. |
173 |
> Also nichts gewonnen. |
174 |
|
175 |
Ach so: Du hast genau einen Rechner, und das ist ein Server mit |
176 |
3 Diensten. Nirgendwo ist ein Desktop mit weiteren Anwendungen und |
177 |
Dokumentationen zugreifbar. Wirklich ein origineller Rechnerpark... |
178 |
|
179 |
Für diese Ausnahmesituation kann es tatsächlich passieren, dass Du |
180 |
einmalig 100 MB mehr Daten laden musst, als wenn Du eine dafür |
181 |
speziell zugeschnittene Distribution hättest. |
182 |
|
183 |
> Wenn die Dynamik so stark wäre, wie könnten dann viele |
184 |
> Softwareprojekte ihre Dokumentation in "Binärform" (PDF, PS, HTML) |
185 |
> online zur Verfügung stellen? |
186 |
|
187 |
Man sieht desöfteren vollkommen veraltete Dokumentation auf Webseiten. |
188 |
Wirklich aktuell ist sie meist nur bei Projekten, die sich selbst |
189 |
kaum verändern (das sind natürlich die meisten), oder die diese |
190 |
automatisiert aus den Sourcen generieren. |
191 |
|
192 |
> Wenn er Binary-Pakete auch für die Software will, kann er die |
193 |
> installieren, wenn er die Software compilieren, aber die Doku als |
194 |
> Binärpaket haben will, um sich nicht LaTeX, SGML-Tools, FileMaker, |
195 |
> OpenOffice und was weiß ich nicht noch alles auf den Rechner |
196 |
> installieren zu müssen, dann könnte er das auch tun. Warum lehnst |
197 |
> Du es so kategorisch ab [...] |
198 |
|
199 |
Weil er bei geänderter Bedeutung des doc-USEflags dann nicht |
200 |
mehr die Dokumentation so wie bisher installieren könnte |
201 |
(außer er macht es händisch). |
202 |
|
203 |
> > Der Unterschied ist, dass man mit dem "doc"-USE-Flag bisher |
204 |
> > die Dokumentation aus den Sourcen bekam (soweit vorhanden), |
205 |
> > man nach Deinem Vorschlag aber zusätzliche Daten herunterladen muss. |
206 |
> |
207 |
> Muß man nicht. Nur wenn das USE-Flag aktiviert ist. Dann ist davon |
208 |
> auszugehen, daß dieser Download gewünscht ist. |
209 |
|
210 |
Nein, beim "doc"-USE-Flags ist nicht davon auszugehen, dass der *Download* |
211 |
erwünscht ist, sondern dass die *Dokumentation* erwünscht ist. |
212 |
Dir ist schon klar, dass Dein letzter Satz für jemanden, der |
213 |
LaTeX installiert hat, sinngemäß folgendes besagt: |
214 |
"Du sollst Dir neuerdings die Dokumentation zusätzlich |
215 |
megabyteweise binär herunterladen, wenn Du sie willst, |
216 |
statt die vorhandene zu installieren, aber das ist ja keine |
217 |
Einschränkung für Dich, denn Du hast ja die Option, auf die |
218 |
Dokumentation zu verzichten." |
219 |
|
220 |
> Und zusätzliche Dateien |
221 |
> muß ich auch herunterladen, wenn ich LaTeX nicht installiert habe. |
222 |
|
223 |
Bei sehr vielen Paketen nicht: Die Dokumentation ist oft schon im |
224 |
Tarball vorhanden, wird ohne doc-Flag aber nur nicht installiert |
225 |
(tetex selbst ist ein schönes Beispiel hierfür). |
226 |
|
227 |
> Da hier bereits feststeht, daß dieser Vergleich ungünstig für LaTeX |
228 |
> ausgeht (1. größerer Download, 2. mehr Zeit zum Compilieren) |
229 |
|
230 |
Nur bei einem verkrüppelten Rechnerpark, der aus einem Miniatur-Server |
231 |
und keinem Client besteht. Insbesondere geht der Vergleich anders herum |
232 |
aus, wenn mindestens ein Desktop-Rechner existiert. |
233 |
Die Compilationszeit ist bei LaTeX übrigens praktisch vernachlässigbar, |
234 |
vermutlich deutlich kürzer als die Zeit zum Download der Binär-PDFs. |
235 |
|
236 |
> Das ist aber nett, daß ich da von Dir die Genehmigung bekäme. Hab ich |
237 |
> das nicht bereits geschrieben, daß ich mir ein "bindoc"-Flag |
238 |
> vorstellen könnte? |
239 |
|
240 |
Aus Bequemlichkeit werden sich die meisten .ebuild-Maintainer dann |
241 |
höchstens für eines der beiden Flags entscheiden und ggf. den Support |
242 |
für doc einstellen. Daher bin ich überhaupt nicht begeistert davon |
243 |
und trete auch so vehement dagegen ein... |
244 |
|
245 |
> Noch einmal ganz langsam: |
246 |
> |
247 |
> 1. Es geht nicht nur um den verschwendeten Platz. |
248 |
|
249 |
Worum dann? Warum sonst wäre es so schlimm für Dich, LaTeX auf dem |
250 |
Rechner zu haben, selbst wenn Du es nur für die Compilation der |
251 |
Dokumentation benutzt? |
252 |
Vor allem so schlimm, dass Du deswegen sogar die Gentoo-Politik bzgl. des |
253 |
doc-USEflags ändern willst oder die Maintainer zum Bereitstellen von |
254 |
binärer Dokumentation bringen willst? (Die Du selbst bequem auf jedem |
255 |
Rechner mit latex in Binärform erstellen könntest?) |
256 |
|
257 |
> 2. Ein Server braucht nunmal kein LaTeX (in den meisten Fällen). |
258 |
|
259 |
Genausosehr oder so wenig wie er gcc und vieles andere braucht: |
260 |
Es kann bequem sein, wenn man es darauf hat, aber es ist nicht |
261 |
*wirklich* nötig (wenn man Binärpakete einspielt). |
262 |
|
263 |
> 3. Ich halte meine Server gerne schlank |
264 |
|
265 |
Aha. Punkt 3 lautet: Punkt 1 ist falsch. ;) |
266 |
|
267 |
> Ich weiß nicht, was Du für Klimmzüge machst, aber meine |
268 |
> Server compilieren ihre Software meistens selbst. |
269 |
|
270 |
Und dieser Satz besagt i.W.: Punkt 3 ist falsch. :) |
271 |
|
272 |
> Da sie immer wieder unterschiedlich in den Anforderungen |
273 |
> sind, unterscheiden sich USE-Flags und CFLAGS (mindestens) nicht |
274 |
> unwesentlich |
275 |
|
276 |
Ja und? Wieso hindert Dich das, die Software auf einem anderen |
277 |
System zu kompilieren, wenn Du den Server um jeden Preis schlank |
278 |
halten willst? |
279 |
|
280 |
> Wozu soll |
281 |
> ein "Mutterrechner" gut sein? Weder meine Kunden noch ich haben |
282 |
> einen leistungsstarken Server übrig, den man für |
283 |
> Systemupdate-Aufgaben abstellen kann bzw. will. |
284 |
|
285 |
Wenn es *keinen* Rechner gibt, auf dem man vernünftig kompilieren kann, |
286 |
ist Gentoo die falsche Distribution. Wenn es einen solchen gibt |
287 |
(auf dem also ohnehin gcc u.ä. laufen) macht latex das Kraut auch |
288 |
nicht fett. |
289 |
|
290 |
> Nicht alle machen es so wie Du. |
291 |
|
292 |
Habe ich auch nicht behauptet: Du hast gefragt, wie andere das machen |
293 |
(diese Frage hast Du leider nicht mitzitiert), |
294 |
und ich habe daraufhin beschrieben, wie *ich* das mache |
295 |
(eben mit "Mutterrechner" usw.). |
296 |
|
297 |
> Was die anderen Lösungen weder als |
298 |
> besser noch als schlechter klassifiziert. Das ist das schöne an |
299 |
> Gentoo ... |
300 |
|
301 |
Und deswegen wehre ich mich gegen einen Vorschlag, der kurz- |
302 |
oder zumindest mittelfristig meine Lösung (und vermutlich die |
303 |
vieler Desktop-User) durch deFacto-Abschaffung des bisherigen doc-Flags |
304 |
beschneidet. Alternativvorschläge (ohne USE-Flag-Änderungen) |
305 |
habe ich ja gemacht... |
306 |
|
307 |
Schöne Grüße |
308 |
Martin |
309 |
|
310 |
-- |
311 |
gentoo-user-de@g.o mailing list |