Das so "wenig" manpages vorhanden sind, liegt glaub ich weniger an Arch-Packetmaintainer als an den Upstreamautoren, die nicht immer manpages schreiben. Im Falle von rar und unrar, stellt der Upstreamautor nähmlich keine Manpage zur Verfügung. Bei Debian muss dann der Maintainer selbst eine Manpage schreiben. Das passt aber nicht so sehr zur KISS-Philosophie von Archlinux.

Meistens hilft dann aber zumindest ein "unrar --help" weiter.

Außerdem denk ich, dass man 95% der Doku, die auf dem Rechner wär, sowieso nicht braucht und dort nur Platz weg nimmt. Und ohne Breitbandinternetzugang ist man mit Archlinux sowieso aufgeschmissen (updates, fehlendes Packet nachinstallieren, ...)

Das die Sache manchmal trotzdem ärgerlich ist, hab ich aber auch schon erfahren müssen.

Das die info-pages fehlen ist Absicht, da man der Meinung ist,dass sie unnötig sind. Siehe Frage 2.10.

cu

Die Sache mit den fehlenden Dokumentationen stört mich auch, stellt aber gleichzeitig so ziemlich die einzige Schattenseite von Archlinux dar. Es gab auch schon des Öfteren Diskussionen darüber, allerdings ohne Erfolg. Leider sieht es - zumindest im Moment - nicht danach aus, dass sich daran etwas ändern wird.

Zwar sind Manpages eigentlich nicht davon betroffen, aber trotzdem nervt es mich persönlich gewaltig, gerade da ich mit dem Lappi eben nicht immer online bin. Das wars dann mit "man sucht doch eh bei google".

Von einigen Paketen, bei denen ich die Doku vermisse, abgesehen, ist info (ob mans mag oder nicht) nunmal zumindest bei GNU die erste Wahl und die Manpages oft nur ein Verweis darauf. Das Speicherplatzargument ist in der heutigen Zeit, meines Erachtens nach, einfach nicht mehr haltbar.

Naja, das Geheule hilft aber nicht weiter; man muss halt damit leben und selbst Hand anlegen.

Zumindest die wichtigsten Infopages gibts in community (coreutils-info), ebenso die Emacs-Dokus (emacs-info). Damit lässt sichs dann schon eher leben. Die anderen wichtigen Sachen muss man dann halt, wohl oder übel, von Hand zusammenklauben und irgendwie aktuell halten.

Noch ein guter Tip für alle diejenigen, welche, wie ich, nicht gerade fans des Standard info-readers sind: community/pinfo.

[P.S. Natürlich kann ich es verstehen, wenn jemand anderer Meinung ist als ich, aber für mich ist gute Dokumentation das A und O -- deshalb ist das schon ein ganz schöner Wermutstropfen für mich, gerade bei einem ansonsten nahezu perfekten BS.]

Ich persönlich empfinde das Weglassen der Info-Pages auch als Fehler. Und die Einstellung "Wenn ich es nicht nutze, soll es auch sonst keiner haben" ziemlich fragwürdig. Das Thema wird recht oft aufgegriffen, was zeigt, daß durchaus Bedarf da ist.

Arch ist aber eine Community-Distribution und wenn man was ändern will, muß man es selbst tun. Folgenden Thread sollte man sich hierzu einmal durchlesen: http://www.archlinux.org/pipermail/arch/2005-April/004194.html

Das Ganze verläuft wohl einfach im Sande, weil es keiner anpackt. Wer dies also ändern möchte, sollte dafür sorgen, daß makepkg entsprechend angepasst wird und dies auf pacman-dev diskutieren.

Denn eine Diskussion die mit "Ich hätte gerne Info-Pages und habe hierzu einen makepkg-Patch geschrieben..." beginnt halte ich für deutlich aussichtsreicher.

Ich denke nicht, daß das undokumentiert ist. Es gib in /etc/makepkg.conf die Sektion
# GLOBAL PACKAGE OPTIONS
und darin

----

# Default: OPTIONS=(strip !docs !libtool emptydirs)
#
#-- strip: Strip symbols from binaries/libraries
#-- docs: Save doc and info directories
#-- libtool: Leave libtool (.la) files in packages
#-- emptydirs: Leave empty directories in packages
#
OPTIONS=(strip !docs libtool emptydirs)

----

Man kann also schon DOCs bekommen - aber nur bei Paketen, die man selbst kompiliert. Bei 1,2 Paketen ist das sicher ok, aber es geht ja eigentlich um die Binär-Pakete die man über pacman von den Servern holt.
Da fände ich eine generelle Lösung hin zu mehr Doku auch sinnvoll.

Wenn dir/euch was fehlt, dann nützt eine Diskussion in diesem Forum wohl nicht sehr viel.
Was Pierre gesagt hat wäre wohl ein möglicher Weg. Siehe

Pierre schrieb Das Ganze verläuft wohl einfach im Sande, weil es keiner anpackt. Wer dies also ändern möchte, sollte dafür sorgen, daß makepkg entsprechend angepasst wird und dies auf pacman-dev diskutieren.

Denn eine Diskussion die mit Ich hätte gerne Info-Pages und habe hierzu einen makepkg-Patch geschrieben... beginnt halte ich für deutlich aussichtsreicher.

cu

Ich glaube bei info-pages ist es mit bloßem "in den richtigen Ordner" kopieren nicht getan. Pacman muß diese wohl auch in einen Index eintragen bzw. wieder austragen können.

makepkg ist übrigens ein reines Bash-Skript; pacman selbst ist in C geschrieben.

Im Zweifel einfach mal mit eigenen Paketen durchtesten, was die Optionen bedeuten und übelegen, wie man das sehr einfach für alle Pakete umsetzen kann.

Die beste Lösung wäre meiner Meinung nach eine Anpassung von makepkg bzw. Pacman, so daß die PKGBUILDs aller Pakete nicht extra modifiziert werden müssen.

Pierre schrieb Ich glaube bei info-pages ist es mit bloßem "in den richtigen Ordner" kopieren nicht getan. Pacman muß diese wohl auch in einen Index eintragen bzw. wieder austragen können.

Wie ich das verstanden habe, müsste man in post_install() install-info für die entsprechenden info-pages aufrufen, so wird es zumindest bei coreutils-info gemacht.

Pierre schriebmakepkg ist übrigens ein reines Bash-Skript; pacman selbst ist in C geschrieben.

Ja, ich hatte bei Pacman irgendwie Python im Kopf, ich glaub das war bei Gentoo :kopfkratz:

Pierre schriebIm Zweifel einfach mal mit eigenen Paketen durchtesten, was die Optionen bedeuten und überlegen, wie man das sehr einfach für alle Pakete umsetzen kann.

Die beste Lösung wäre meiner Meinung nach eine Anpassung von makepkg bzw. Pacman, so daß die PKGBUILDs aller Pakete nicht extra modifiziert werden müssen.

Wenn ich es richtig verstanden habe, bewirkt die docs-Option, dass die Dokumentationsverzeichnisse (DOC_DIRS) nicht gelöscht werden. Ohne diese Option werden gemäß der makepkg-duties, Punkt 6 (Arch Packaging Standards) die Verzeichnisse /usr/doc, /usr/info, /usr/share/doc und /usr/share/info gelöscht. (Korregier mich, wenn ich da irgendwas falsch verstanden habe)

Bisher dachte ich immer, dass man bereits im eigenen PKGBUILD diese Verzeichnisse zu löschen hätte und habe das auch immer so getan. Das werde ich dann wohl bei den von mir 'maintainten' Paketen ändern.

Du sagst: "so daß die PKGBUILDS aller Pakete nicht extra modifiziert werden müssen". Heißt das, dass auch in anderen PKGBUILDS die entsprechenden Verzeichnisse gelöscht werden (also so, wie ich es bisher gehalten habe)? So richtig steig ich da glaube ich im Moment noch nicht durch. Wenn es so ist, dass die Pakete ihre Dokumentation bereits im PKGBUILD löschen, gibt es doch überhaupt keine andere Möglichkeit, als diese PKGBUILDS zu ändern? Oder meinst Du so etwas wie eine makepkg-Option, die aus dem src-Verzeichnis die Dokus 'rettet', sprich falls sie im PKGBUILD gelöscht werden wieder ins pkg-Verzeichnis kopiert?

Und wenn dann diese Probleme gelöst wären, müsste man Pacman wohl so patchen, dass er je nach Konfiguration entweder die Dokumentation mit installiert, oder eben nicht. (Das heißt, dass die Dokumentation in allen Paketen erst mal drin ist und dann erst 'vor Ort' entschieden würde, ob sie installiert werden oder nicht. (?)

Öhm nein, nicht so kompliziert. makepkg löscht eben jede Docu außer den manpages. Im PKGBUILD selbst muß hierzu nichts angegeben werden. Das Ziel sollte sein, daß zwar die docs weiterhin gelöscht werden, evtl. vorhandene info-pages nicht.

Das Registrieren der info-pages sollte pacman selbst übernehmen und nicht in das install-script verlegt werden.

Pierre schrieb Öhm nein, nicht so kompliziert. makepkg löscht eben jede Docu außer den manpages. Im PKGBUILD selbst muß hierzu nichts angegeben werden. Das Ziel sollte sein, daß zwar die docs weiterhin gelöscht werden, evtl. vorhandene info-pages nicht.

Gut, dann hab ich es jetzt richtig verstanden. Bisher dachte ich, dass man sich schon im PKGBUILD darum kümmern müsste. Ich denke auch, dass ich im AUR schonmal ein paar PKGBUILDS gesehen habe, die das so machen. Schonmal ein positiver Nebeneffekt des Threads, wenn auch nur für mich 😉

Damit makepkg bloß die docs löscht, sollte folgender Eintrag in der makepkg.conf genügen:

DOC_DIRS=(usr/doc usr/share/doc)

Wenn nun docs nicht im OPTIONS array gesetzt ist, werden nur die docs gelöscht, die info-pages bleiben unangetastet [nicht getestet!]. Wenn dieser Eintrag also per default in der makepkg.conf wäre, würde sich das Problem auf pacman reduzieren.

Pierre schrieb Das Registrieren der info-pages sollte pacman selbst übernehmen und nicht in das install-script verlegt werden.

Ich weiß nicht, ob ich dazu in der Lage wäre, solch einen Patch zu schreiben. Erstens hab ich noch nie sowas gemacht, zweitens müsste ich mich erst mal ordentlich in die pacman-Quellen einlesen und selbst wenn ich das hinbekommen würde ist die Frage, ob ich mich nicht damit übernehme. Naja, ich probiere jedenfalls mal mich in der nächsten Zeit in pacman einzulesen, vielleicht kann ich ja doch was auf die Beine stellen, aber macht euch nicht allzuviele Hoffnungen 😉

Ich habe es mir auch nicht angesehen und meine C-Kenntnisse sind ehrlich gesagt auch nur rudimentär. Ein guter Einstiegspunkt ist sicher die Stelle, die post_upgrade bzw. post_install aufruft.

Bei konkreten Fragen am besten direkt bei pacman-dev melden.

Ich hab mir jetzt mal die Quellen per CVS gekrallt und schau mal, ob ich da durchsteigen kann. Probieren kann man's ja mal.

Am besten mal in der git-Version schauen. Bei cvs weiß ich nicht, ob das noch verwendet wird.