Re: manpages-l10n: Debian Buster durch Bullseye ersetzen?
Hallo Helge,
Am So., 5. Jan. 2020 um 07:06 Uhr schrieb Helge Kreutzmann
<debian@helgefjell.de>:
>
> Hallo Mario,
> On Fri, Jan 03, 2020 at 10:43:40PM +0100, Mario Blättermann wrote:
> > im Projekt manpages-l10n wäre es wieder Zeit für eine
> > Upstream-Aktualisierung. Wir haben derzeit noch Debian Buster drin,
> > was aber wohl kaum noch wichtig ist. Wenn überhaupt, wäre eine
> > Auslieferung der manpages-*-Pakete nur über die Backports möglich.
> > Wäre es an der Zeit, Buster zu entfernen und auf Bullseye zu wechseln?
>
> Und genau das machen wir doch?
>
Nein, eben nicht. Wir haben immer noch die Handbuchseiten aus Buster
im Programm. Bekanntermaßen gibt es keine Möglichkeit, in eine bereits
veröffentlichte Debian-Version neue Paketversionen einzubringen. Das
geht nur über die Backports, die möglicherweise nicht allzu viele Fans
haben, so dass letztendlich kaum neue oder aktualisierte
Handbuchseiten beim Leser ankommen.
> Ich würde gerne Sid + Stable, d.h. derzeit Sid + Buster behalten.
> Bullseye (Testing) bringt dagegen gar nichts, wohin soll das denn
> hochgeladen werden?
>
Keine Ahnung, das geht über meine Kenntnisse zu Debian hinaus. Vergiss
die Idee einfach, hinsichtlich Debian bin ich sowieso
leidenschaftslos.
> > Das würde ich nämlich gerne noch vor der Aktualisierung machen, um
> > Zeit zu sparen. Ich habe bei der vorletzten Prozedur Ende November mal
> > die Zeiten notiert, die für die einzelnen Schritte nötig sind (die
> > später hinzugekommenen polnischen Dateien sind noch nicht
> > berücksichtigt):
>
> …
>
> > Wenn man mal die Aktualisierungen der nicht-deutschen *.po-Dateien
> > außen vor lässt, die eigentlich Sache der jeweiligen Sprachteams sind,
> > dauert das Ganze auf meinem Rechner etwa eineinhalb Stunden. Daher ist
> > mir sehr daran gelegen, hier und da etwas einsparen zu können.
>
> Muss dass denn alles sequenziell laufen? Wäre es nicht eher sinnvoll,
> mittelfristig die Infrastruktur auf einen parallelen Lauf zu
> aktualisieren? Die Sprachen sollten doch auf jeden Fall parallel
> laufen könne, eigentlich auch die Distributionen, oder?
>
Die Aktualisierung der Upstream-Pakete läuft seriell, braucht aber bei
mir auch nur 15 Minuten. Das geht alles noch. Aber auch wenn es
parallel laufen würde, setzt der Rechner seine natürlichen
Leistungsgrenzen. Ganz allein vor sich hin rödeln lassen kann man
diese Prozedur auch nicht. Da ist immer mal was zwischendurch zu
korrigieren, zum Beispiel wenn sich aus einer Handbuchseite wegen
Syntaxfehlern keine Vorlage bauen lässt oder bei Umbenennungen oder
so.
Das größte Problem ist das Skript templates/update-all-templates.sh.
Das arbeitet nacheinander die Po-Dateien aller Sprachen ab, aber
dupliziert vieles. Der erste Befehl im Skript liefert derzeit folgende
Verzeichnisliste:
de/man1
de/man2
de/man3
de/man4
de/man5
de/man6
de/man7
de/man8
fr/man1
fr/man2
fr/man3
fr/man4
fr/man5
fr/man6
fr/man7
fr/man8
nl/man1
nl/man2
nl/man3
nl/man4
nl/man5
nl/man6
nl/man7
nl/man8
pl/man1
pl/man2
pl/man3
pl/man4
pl/man5
pl/man6
pl/man7
pl/man8
ro/man1
ro/man5
Die Liste wird dann sequenziell abgearbeitet. Nun ist es aber so, dass
sich beispielsweise eine Datei namens man1/chmod.1.po in allen
Sprachverzeichnissen befindet und daher fünfmal eine neue Vorlage
chmod.1.pot erstellt wird. Diese Verzeichnisliste ist bei mehreren
Sprachen einfach der falsche Ansatz. Das Skript müsste gleich eine
Dateiliste bauen, in der es keine Duplikate gibt. So könnte man die
derzeit für die Ausführung nötigen 44 Minuten auf vielleicht 25
Minuten schrumpfen lassen. Das wäre schon mal ein Fortschritt. Nur
leider würde ich das mit meinen bescheidenen Kenntnissen nicht
hinkriegen. Jedenfalls würde es wohl so lange dauern, bis es
funktioniert, dass der Zeitvorteil wieder dahin wäre.
Einmal ziehe ich die Aktualisierung mit den derzeitigen Skripten noch
durch, aber dann reicht es mir auch. Eineinhalb Stunden sind einfach
zu viel. Zwanzig Minuten weniger sind aber auch noch kein Meilenstein,
deswegen brauchen wir auch für die Upstream-Pakete eine andere Lösung.
Derzeit werden die Verzeichnisse in usptream/*/man* komplett geleert
und *alles* neu heruntergeladen und entpackt. Wir müssten
Versionsnummern in upstream/*/packages.txt hinzufügen und das Skript
so ändern, dass nur noch Pakete heruntergeladen werden, deren
Versionsnummer auf dem Server neuer als die in der Paketliste ist.
Danach müssen auch nur die Vorlagen erstellt werden, für die es
tatsächlich neue Originalhandbuchseiten gibt. Insgesamt würde sich der
Zeitaufwand damit dauerhaft auf deutlich unter eine Stunde drücken
lassen, was bei einer oder zwei Aktualisierungen pro Monat durchaus
akzeptabel ist. Ich weiß, das Umstellen der Skripte ist viel Arbeit
und ich kriege das selbst nicht hin, aber ich möchte meine Freizeit
lieber in die Übersetzungen selbst investieren als in das Starten von
Skripten, die vieles doppelt, drei- oder fünffach abarbeiten.
Möglicherweise kommen ja auch noch mehr Sprachen und/oder
Distributionen hinzu, was wieder mehr Zeit bedeutet.
Die Aktualisierungen seltener auszuführen ist auch keine Lösung, damit
schießen wir uns selbst ins Knie und werden den zweifelhaften Ruf
niemals los, dass übersetzte Handbuchseiten den Originalen zeitlich
weit hinterherhinken. Die bedingungslose Aktualität ist ja gerade das
Argument, mit dem ich bestehende Sprachteams anzulocken versuche. Was
soll ich denen denn sagen, wenn wir vielleicht nur noch vier Mal im
Jahr aktualisieren und zwei Mal einen neuen Tarball
veröffentlichen...? Außerdem würde ich so etwas den Benutzern auch
nicht zumuten wollen, gerade als Nutzer einer
Rolling-Release-Distribution, die auf Aktualität zwingend angewiesen
ist.
Gruß Mario
Reply to: