Hallo Mario,
On Tue, Dec 22, 2020 at 04:39:08PM +0100, Mario Blättermann wrote:
> Am Di., 22. Dez. 2020 um 13:17 Uhr schrieb Helge Kreutzmann
> <debian@helgefjell.de>:
> > On Mon, Aug 03, 2020 at 08:14:57PM +0200, Mario Blättermann wrote:
> > > ich habe neulich gemerkt, dass im Mageia-Paket man-pages-de-4.1.0 [1]
> > > keine Links enthalten sind, sondern nur reguläre Manpage-Dateien. Seit
> > > Jahr und Tag installieren wir in /usr/share/man/de/man? die gleichen
> > > Links wie in /usr/share/man/man?, und ich dachte immer, das müsste so
> > > sein.
> >
> > D.h. in Magei wird die gleiche Handbuchseite mehrfach abgelegt? Also
> > tzset(3), tzname(3), timezone(3), daylight(3) statt einmal tzset(3)
> > und drei Links wie z.B. hier auf Debian?
> >
> Nein, die wird nicht mehrfach abgelegt, wieso das denn...? In Mageia
> gibt es genau solche symbolischen Links wie woanders auch, aber eben
> nicht in den sprachbezogenen Unterverzeichnissen von /usr/share/man.
Ok, Du konzentrierst Dich nur auf die übersetzen Datei.
> > > Zuerst habe ich die fehlenden Links im Mageia-Paket für einen Bug
> > > gehalten, irgendeinen Fehler in unserer Toolchain oder der auf dem
> > > Mageia-Buildserver. Aber dann habe ich es erst einmal selbst getestet.
> > > Die Manpage accept4.2 ist ein Link auf accept.2. Wenn ich auf meinem
> >
> > Das ist ja auch gut so. Denn sowohl accept als auch accept4 werden in
> > dieser Handbuchseite beschrieben.
> >
> > > Archlinux in /usr/share/man/man2 explizit den Befehl »man
> > > ./accept4.2.gz« aufrufe, bekomme ich trotzdem die richtige, von meiner
> > > Spracheinstellung abhängige Datei /usr/share/man/de/man2/accept.2.gz
> >
> > Das ist merkwürdig. Du verlangst explizit eine Seite und das System
> > zeigt Dir eine andere, hier die lokalisierte, an?
> Das ist nicht so einfach. Ich rufe zwar den Link explizit auf, aber
> was soll mir hier angezeigt werden? Da ist nichts. Logischerweise geht
> es zur Zieldatei. In diesem speziellen Fall schaltet sich die
> Locale-Einstellung ein und leitet das Link-Ziel auf die übersetzte
> Version um. Dieses Verhalten kann ich nur durch Wechsel der Locale mit
> LC_ALL=C beeinflussen.
>
> > Auf meinem
> > Debian-System verhält sich das System deterministischer, hier wird die
> > englische Seite angezeigt.
> >
> > Hast Du die Links noch oder nicht mehr?
> >
> > > angezeigt. Rufe ich dagegen »man ./accept.2.gz« auf, bekomme ich die
> > > englische Version. Das heißt, dass all die Link-Duplikate in den
> >
> > Ich auch.
> >
> > > sprachbezogenen Unterverzeichnissen von /usr/share/man überflüssig
> > > wären. Könntet ihr das mal bitte auf euren Systemen testen, ob es auf
> > > Debian auch funktioniert? Dann könnten wir nämlich in Zukunft darauf
> > > verzichten, die Links zu installieren.
> >
> > Also Dein erstes Beispiel verstößt gegen die Annahme der geringsten
> > Überraschung und zumindest auf Debian funktioniert es nicht. Daher
> > würde ich davon abraten, Mikrooptimierung vorzunehmen, Links kosten
> > nicht viel Platz (praktisch keinen) und das System läuft ja auch.
>
> »Debian« müssten wir hier wahrscheinlich auf »Buster« beschränken,
Nein, ich bin auf Testing, also gemäß unserer Nomenklatur
debian-unstable. (man-db unter Debian, derzeit in Testing und Unstable
versionsidentisch)
> siehe unten. Es geht auch nicht um den Platzbedarf. Vielmehr ist die
> Linkerzeugung eine Fehlerquelle, die ich gern ausschalten würde. Bei
> den Upstream-Aktualisierungen ist es schon oft passiert, dass die
> links.txt-Dateien nach der Download-Prozedur leer waren und ich noch
> mal von vorn anfangen konnte. Mittlerweile kenne ich einige der
> möglichen Ursachen, aber ganz ohne Linkerzeugung würde die Fehlersuche
> wegfallen.
>
> > Und
> > einige Seiten x-fach auszuliefern fände ich auch keine gute Idee.
>
> Das passiert doch gar nicht. Wie weiter oben beschrieben, werden
> weiterhin symbolische Links und keine Duplikate ausgeliefert.
>
> Ich würde sagen, wir belassen es dabei. Vielleicht ist es ein neueres
> Feature der Manpage-Hierarchie, und das kommende Debian Bullseye zeigt
> vielleicht das gleiche Verhalten wie derzeit Archlinux und Mageia.
> Dann können wir die Sache später noch einmal aufgreifen.
Ok, aber ich würde nicht drauf wetten. Ich vermute eher, dass das
irgendwo konfiguriert ist, leider bin ich beim Lesen von man(1) nur
auf eine inkorekte Übersetzung aber nicht die Lösung des Problems
gestoßen. Da Du der letzte Übersetzer von man(1) bist, könntest Du die
Korrektur (oder eine entsprechende) dort übernehmen:
@@ -1853,10 +1853,10 @@ msgstr ""
"Einige Systeme integrieren umfangreiche Handbuchseiten-Pakete, wie z. B. "
"Zubehör für das B<Tcl>-Paket, in die normalen Abschnitte. Für die Lösung des "
"Problems zweier unterschiedlicher Handbuchseiten mit gleichem Namen, wie "
-"B<exit>(3), wurden früher alle B<Tcl>-Seiten dem Abschnitt B<l> zugeordnet "
-"und mit einer speziellen Endung versehen, in diesem Fall B<exit>(3tcl). Dies "
-"erwies sich als unglückliche Lösung. Diese Version von B<%man%> ermöglicht "
-"es, die Seiten in die richtigen Abschnitte einzuordnen und ihre. "
+"B<exit>(3), wurden früher alle B<Tcl>-Seiten dem Abschnitt B<l> zugeordnet."
+" Dies "
+"erwies sich als unglückliche Lösung. Diese Version von B<%man%> ermöglicht "
+"es, die Seiten in die richtigen Abschnitte einzuordnen und ihnen bestimmte Endungen, in diesem Fall "
"B<exit>(3tcl), anzufügen. Im Normalbetrieb zeigt B<%man%> bevorzugt "
"B<exit>(3) gegenüber B<exit>(3tcl) an. Um diese Situation zu bewältigen, "
"können Sie B<%man%> die Zeichenkette I<Unter-Erweiterung> übergeben. Diese "
Viele Grüße
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: PGP signature