[Eisfair_dev] Neu: man-Pages auf eisfair

[Kay Martinen]

Am 22.11.20 um 12:56 schrieb Marcus Röckrath:
> Hallo Paketentwickler,

Bin ich zwar nicht, dennoch my 2ct.

> ab sofort dürfen auch man-Pages auf dem eisfair "installiert" werden.

Ich wusste nicht mal das die bisher *nicht* installiert werden *durften*!

> Die man-Pages sollen/müssen aber in ein eigenes Paket ausgelagert werden,
> ähnlich einem -dev-Paket.

Warum? Warum nicht in einem Paket das z.b. joe enthielte, oder den
inetutils-deprecated (oder wie auch immer netstat, route usw. jetzt heißen)?

Vermutung: Weil Eisman kein Recommend vs. suggest als Beziehung zwischen
Paketen kennt?


> Beispiel:
> 
> Paket: xyz
> man-Paket: xyz-doc

Fände ich; als user; unlogisch. xyz-man wäre deutlich intuitiver - wenn
es denn schon so sein muß.

> 
> 
> In der Infodatei des xyz-doc-Paketes:
> 
> <name>xyz-doc</name>
> <section>doc</section>
> <system>eisfair-noarch</system>
> 
> Hat das xyz-Paket das <short>-Tag
> 
> <short>xyz - Tool for ...</short>
> 
> dann bekommt das doc-Paket den Tag
> 
> <short>DOC: xyz - Tool ...</short>
> 

Warum eigentlich DOC und nicht MAN?

Bei DOC denke ich direkt erst mal an Komplett-DokumentationsPakete (bei
$otherlinux, z.b. für Exim-Doc) oder an das 'info' tool das IMHO
historisch eher das ist was die längeren und ausführlicheren
Dokumentationen enthielte. man-pages sehe ich eher als "ausführlicher
als 'tool -h'" aber kürzer als 'info <tool>'

Mein Vorschlag:
<short>MAN: xyz - Tool, man-pages...</short>


> Ein doc-Paket hat kein Verzeichnis /usr/share/doc/<paketname>, wie dies auch
> für lib- und -dev-Pakete gilt, also insbesondere auch keine changes-Datei.

Ich kenne bei man-pages nur eine art "Version x.y <date>" am Ende des
Textes.

> Das info-File des Hauptpaketes bekommt zusätzlich
> 
> <linked-package>xyz-doc <versionsnummer></linked-package>

Sorgt das dann für das automatische nachladen des man-paket wenn man das
tool installiert?

> Es erledigt sich damit die manchmal geübte Praxis, man-Pages als
> umgewandelte Textdateien in der Dokumentation des Hauptpaketes
> in /usr/share/doc/<paketname>/<paketname.txt> unterzubringen.

Ach so. Die Verwandschaft ist mir bisher nicht sehr aufgefallen da
zuerst die TOOL_X_NAME u.s.w. Parameter und das Menü beschrieben werden.

Oft kommt am Ende dann etwas das eher so aussieht.

> Derzeit gibt es schon eine Handvoll Pakete, die das nun so umsetzen, die man
> sich auch mal anschauen kann:
> 
> nano, minipro, picocom, hstr, columscat

Davon habe ich nur nano installiert, benutze ihn aber selten.

Eine Anregung hätte ich noch aber ich weiß nicht ob die schwer oder
unmöglich um zu setzen wäre. Die Kontext-Hilfe (F1) im ECE enthält bei
vielen Einträgen keine Infos.

Ob es möglich wäre den Parameter den so ein Eintrag manipuliert in der
man-page automatisiert zu lokalisieren und für diesen Hilfetext zu
markieren, taggen oder zu importieren. Das könnte entweder beim
Paket-erstellen einmalig oder beim Installieren/update durch einen
indizierungs-durchlauf einmalig gemacht werden. Und es würde die
verfügbarkeit von aussagekräftigeren Hilfstexten im ECE sicherlich
schnell und deutlich verbessern.

Z.B. Wenn im Samba paket der Parameter für WORKGROUP keine F1 Hilfe im
ECE hätte dann könnte man in 'man 5 smb.conf' danach suchen. Nur wie man
dann alles andere ausfiltert und nur den Passenden Block wie diesen hier
(aus meinem ubuntu)

>  workgroup (G)
> 
>            This controls what workgroup your server will appear to be in when queried by clients. Note that this parameter also
>            controls the Domain name used with the security = domain setting.
> 
>            Default: workgroup = WORKGROUP
> 
>            Example: workgroup = MYGROUP

findet und übernimmt weiß ich nicht. Bei Samba könnte man noch nach dem
(G) für globale Parameter filtern aber es scheint als müsse man das
Konfig-bezogen jeweils neu an passen. Doch wohl nicht so leicht... Oder?


Kay

-- 
Posted via leafnode