On Mon, Apr 10, Ralf Corsepius wrote:
Thorsten Kukuk wrote:
On Sun, Apr 09, Clemens Wohld wrote:
Philipp Thomas schrieb am 9.04.00 um 11.04 Uhr
* Walther, Christoph (Christoph.Walther@telekom.de) [20000407 12:22]:
Ferner hält sich SuSE nicht konsequent an den UNIX-Standard, was das Dateisystem anbelangt.
Also entschuldige bitte, aber das ist Kappes, denn *den* UNIX Standard gibt es nicht! Worum wir uns bemühen, ist Kompatibilität zu einem Standard, der tatsächlich existiert, dem FHS (Filesystem Hierarchy Standard) bzw. LSB (Linux Standard Base). Und da ist keine Distribution näher dran als wir. Was bitte können wir dafür, das andere Linux Distributoren offensichtlich weniger daran interessiert sind?
Hm,....was aber ist /sbin/init.d ??? Gehört das nicht (nach FHS, LSB) nach /etc ??
Nein. Nach FHS gehört es auf keinen Fall nach /etc.
Könntest Du das bitte ausführen.
Habe ich.
Ich halte das für eine bestreitbare Behauptung, da der FHS dies nach meinem Verständnis nicht in dieser Bestimmtheit ausdrückt:
Wenn es der FHS Festlegen würde, warum tut sich dann LSB so schwer, eine Begründung für oder gegen init Skripte in /etc/ zu finden ?
<FHS> 3.4 /etc : Host-specific system configuration
/etc contains configuration files and directories that are specific to the current system.
No binaries should be located under /etc. [..] Notes:
The setup of command scripts invoked at boot time may resemble System V or BSD models. Further specification in this area may be added to a future version of this standard. </FHS>
Den letzten Satz halte ich für einen klaren Hinweis darauf, dass "command scripts invoked at boot time" (zu denen /sbin/init.d/* gehören) unter /etc nicht ausdrücklich verboten sind, es den Autoren aber bewußt ist, dass /etc/init.d problematisch ist.
Genau. Und es steht dort auch nicht, das es erlaubt ist.
/sbin/init.d enthält ausführbare Scripte, die definitiv keine Konfigurationsdateien sind.
Auch dies würde ich nicht in dieser Bestimmtheit ausdrücken.
Doch. Definitiv. Du editierst nicht die Scripte, umd Deine Konfiguration zu ändern. Du editierst die Links oder die Variablen in /etc/rc.config.
* Das Vorhandensein eines /sbin/init.d/<runlevel>/* Skripts stellt in gewissem Sinne eine Konfiguration dar.
Ja, habe ich ja weiter unter gesagt.
* Bootscripte Skripte können lokale Anpassungen (Konfiguration) erfordern (insb. boot.local/halt.local, boot/*).
Ja, trotzdem bleiben es ausführbare Dateien.
* /sbin/init.d/* sind in der Regel "Executables", jedoch keine "Binaries".
Diese Unterscheidung würde ich nicht machen. Im ganzen FHS wird meines Wissens nach nicht explizit von Scripten gesprochen, sondern immer nur von "Binaries".
* Der FHS sagt "should be", im Sinne einer "nachdrücklichen Empfehlung", aber nicht "must" oder "mandates" o.ä.
Eben, im Sinne einer "nachdrücklichen Empfehlung", an die wir uns halten. Also folgen wir damit dem FHS.
Laut FHS darf aber unter /etc nichts ausführbares liegen, sondern nur Konfigurationsdateien. Siehe oben, der FHS spricht von "Binaries" und nicht aber von "Executables".
Ja, der FHS spricht nie explizit von Scripten. Er spricht immer nur von Binaries. Nach Deiner Argumentation darfst Du auch keine Scripte in /bin, /usr/bin oder sonsteinem bin Verzeichnis haben, weil es heißt für diese Verzeichnisse immer "für Binaries".
Doch wenn man "Binaries" mit "ausführbaren Dateien" gleichsetzt, so ist SuSE nicht konsequent. Selbst unter 6.4 enthält /etc/* immer noch "ausführbare Dateien" (z.B.: /etc/filesystems), von "ausführbaren Dateien" unter /etc/*/* (z.B.
^^^^^^^^^^^^^^^^^^ # dir /etc/filesystems -rw-r--r-- 1 root root 24 Mar 24 14:55 /etc/filesystems Wo ist das ausführbar ?
/etc/cron.d/*, /etc/pppd/*) mal ganz zu schweigen.
Ja, darüber könnte man sich unterhalten.
Korrekt nach FHS wäre wahrscheinlich die Lösung, die ich schon mal auf einem kommerziellen Unix gesehen habe: /sbin/rc.d enthält die Scripte, /etc/rc?.d enthält die Links für die Run-Level. Soweit ich den FHS verstehe, dürfte dies im Sinne der FHS-Autoren sein (In meinem Verständnis stellt das Vorhandensein eines Runlevel-Links eine Konfiguration dar).
LSB schweigt sich zu diesem Thema noch aus. Da es im FHS nicht dokumentiert ist, fehlt es den Leuten an Argumenten, was richtig ist.
Lass es mich mal so ausdrücken, /sbin/init.d steht sicher nicht im Widerspruch zum FHS.
---
Andererseits hält sich SuSE nicht an den FHS an Stellen, an denen der FHS eindeutig ist, z.B. /usr/share: /usr/share/doc statt /usr/doc
Darüber kann man sich wieder streiten. /usr/share/doc enthählt laut FHS Dokumentation, die Architekturunabhängig ist. Dieses gilt für unsere Dokumentation dort nicht. Aber ich stimme Dir bei, das, um den FHS voll zu erfüllen (was wir noch nicht machen und was wir ja auch nicht behaupten), dieses Verzeichnis verschoben werden sollte.
/usr/share/dict statt /usr/dict
? /usr/dict ist FHS conform ein Link auf /usr/share/dict. Wo ist das Problem ?
usw.
Was usw. ? Wenn Du schon Behauptungen aufstellst, dann belege Sie auch. Dann kÖnnen wir das zur nächsten Release ändern.
[Soweit ich sehe, scheint Euch dies bewußt zu sein, da seit 6.4 /usr/share/man statt /usr/man verwendet wird - Interessanterweise wurde /usr/man aber nicht eliminiert.]
/usr/share/man wird schon seit 6.2 benutzt. Es dauert nur 1800 Pakete umzustellen. Leider kann RPM den move /usr/man -> /usr/share/man nicht gescheit handeln, weswegen z.B. Red Hat diese Änderung im FHS gerne wieder Rückgängig gemacht hätte. Wir haben uns deswegen entschieden, die alten Verzeichnisse zu lassen, damit es beim Update und bei der Installation von Paketen, die /usr/man benutzen, keine Probleme mit RPM gibt. Tschau, Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com