Re: [RFR] man://manpages-de/PKGBUILD.5.po (Teil 4/6)
Hallo Helge,
Am So., 9. Dez. 2018 um 18:36 Uhr schrieb Helge Kreutzmann
<debian@helgefjell.de>:
> > #. type: Plain text
> > msgid ""
> > "Allow the use of user-specific buildflags (CPPFLAGS, CFLAGS, CXXFLAGS, "
> > "LDFLAGS) during build as specified in B<makepkg.conf>(5)\\&. More useful in "
> > "its negative form !buildflags with select packages that have problems "
> > "building with custom buildflags\\&."
> > msgstr ""
> > "ermöglicht die Nutzung benutzerdefinierter Buildflags (CPPFLAGS, CFLAGS,"
> > " CXXFLAGS, LDFLAGS) während des Bauvorgangs, wie in B<makepkg.conf>(5)"
> > " angegeben\\&. Dies ist in der negierten Form »!buildflags« am nützlichsten,"
> > " wenn Pakete Probleme beim Bau mit benutzerdefinierten Buildflags haben\\&."
>
> s/Buildflags/Bauschalter/
> (hier sehe ich das wie oben bei den Recommends etc, es ist die
> Bschreibung, nicht der Name des Feldes gemeint.
>
Mag sein, aber helfen wir dem Leser wirklich, wenn wir aus Buildflags
Bauschalter machen? Ich denke eher nicht. Flags sind laut Wortliste
zulässig, wenngleich es erst an dritter Stelle steht. In der
Übersetzung von Make (beim GNU TP) kommt »Build« zweimal vor: einmal
als Bauaufgabe und dann noch als Bau-Auftrag. Nicht konsistent, und
beides klingt nicht. »Build« gehört durchaus zum Jargon von
Entwicklern (zu denen ich auch in begrenztem Umfang Paketbetreuer
zähle), es steht nicht in der Wortliste und größere Teile einer
Build-Umgebung sind ohnehin nicht übersetzt, zum Beispiel Cmake,
Automake, die Configure-Skripte, Scons … alles nicht lokalisiert.
Deshalb würde ich es einfach bei Buildflags belassen.
> > #. type: Plain text
> > msgid ""
> > "Allow the use of user-specific makeflags during build as specified in "
> > "B<makepkg.conf>(5)\\&. More useful in its negative form !makeflags with "
> > "select packages that have problems building with custom makeflags such as -"
> > "j2 (or higher)\\&."
> > msgstr ""
> > "ermöglicht die Nutzung benutzerdefinierter Makeflags, wie in B<makepkg.conf"
> > ">(5) angegeben\\&. Dies ist in der negierten Form »!makeflags« am"
> > " nützlichsten, wenn Pakete Probleme beim Bau mit benutzerdefinierten"
> > " Makeflags haben, wie -j2 (oder höher)\\&."
>
> s/Makeflags/Make-Schalter/ (mehrfach)
Siehe oben. Es bleibt bei Makeflags.
> > #. type: Plain text
> > msgid ""
> > "Add the user-specified debug flags (DEBUG_CFLAGS, DEBUG_CXXFLAGS) to their "
> > "counterpart buildflags as specified in B<makepkg.conf>(5)\\&. When used in "
> > "combination with the \\(oqstrip\\(cq option, a separate package containing "
> > "the debug symbols is created\\&."
> > msgstr ""
> > "fügt die benutzerdefinierten Debug-Flags (DEBUG_CFLAGS, DEBUG_CXXFLAGS) zu"
> > " den korrespondierenden Buildflags hinzu, wie in B<makepkg.conf>(5)"
> > " angegeben\\&. Wird dies in Verbindung mit der Option »strip« verwendet, wird"
> > " ein separates Paket erstellt, das die Debug-Symbole enthält\\&."
>
> s/Debug-Flags/Fehlersuchschalter/
Zum Thema Flags→Schalter, siehe oben. Die Wortliste meint dazu:
debugging ... - Debug- (z.B. debugging library), (interaktive) Fehlersuche
Debug ist also in Zusammensetzungen durchaus OK, und Flags auch, wie
schon erwähnt.
> s/Buildflags/Bauschaltern/
>
Siehe oben.
> > #. type: Plain text
> > msgid "B<package() Function>"
> > msgstr "B<package() Funktion>"
>
> s/package() Funktion/package()-Funktion/
OK.
> > #. type: Plain text
> > msgid ""
> > "The package() function is used to install files into the directory that "
> > "will become the root directory of the built package and is run after all the "
> > "optional functions listed below\\&. The packaging stage is run using "
> > "fakeroot to ensure correct file permissions in the resulting package\\&. All "
> > "other functions will be run as the user calling makepkg\\&."
> > msgstr ""
> > "Die package()-Funktion wird zum Installieren von Dateien in das Verzeichnis"
> > " verwendet, das zum Wurzelverzeichnis des gebauten Pakets wird\\&. Sie wird"
> > " nach allen nachfolgend beschriebenen optionalen Funktionen ausgeführt\\&."
> > " Die Paketierungsstufe wird in einer Fakeroot-Umgebung ausgeführt, um die"
> > " korrekten Zugriffsrechte des sich ergebenden Pakets sicherzustellen\\&. Alle"
> > " weiteren Funktionen werden unter dem Benutzernamen »makepkg« und dessen"
> > " Rechten ausgeführt\\&."
>
> Ich finde s/weiteren/anderen/ ist klarer.
>
OK.
> s/dem Benutzernamen »makepkg«/Namen des Benutzers, der Makepkg ausführt,/
> besser:
> Alle anderen Funktionen laufen under der Kennung und mit den gleichen
> Rechten wie der Benutzer, der Makepkg ausführt.
>
Ich dachte, der Bau läuft tatsächlich unter dem Namen des speziell
dafür zur Verfügung stehenden Benutzers »makepkg«, auch wenn das
Original hier etwas anders lautet. Die Fakeroot-Umgebung gehört in
diesem Fall nicht »root«, sondern »makepkg«. Doch das war anscheinend
nur früher mal so, ich hatte ja schon vor ein paar Jahren Pakete für
Archlinux gebaut und dann längere Zeit pausiert. Keine Ahnung, wann
und warum das geändert worden ist. Deswegen hatte ich eben genau diese
Formulierung gewählt. Aber jetzt habe ich natürlich deine Version
übernommen.
Alles nicht Erwähnte habe ich ebenfalls übernommen.
Gruß Mario
Reply to: