Mailinglist Archive: opensuse-de (5757 mails)
| < Previous | Next > |
Re: LSB-Konfomität der Distributoren (was: mysql)
- From: jsj-hb@xxxxxxxxxxx (Stefan Schmidt)
- Date: Thu, 31 Oct 2002 07:38:45 +0100
- Message-id: <200210310738.45966.jsj-hb@xxxxxxxxxxx>
Hi,
On Thursday 31 October 2002 07:14, Ralf Corsepius wrote:
> Am Mit, 2002-10-30 um 10.26 schrieb Thorsten Kukuk:
> > On Wed, Oct 30, Ralf Corsepius wrote:
> > > Gegenfrage: Wie soll ich (distributionsübergreifend) einen
> > > Daemon installieren, wenn die Installation von
> > > init.d-Scripten durch die LSB-initd-Scripte nicht abgedeckt
> > > sind und Detail-Wissen über die proprietären Tools erfordern?
> >
> > Kommt darauf an, woher Du den Daemon hast. Wenn er Bestandteil
> > der Distribution ist, mit Distributions-Board-Mittel. Wenn er
> > eine LSB-Applikation ist, mit den entsprechenden LSB-Tools. Wo
> > ist das Problem?
>
> Wir reden aneinander vorbei: ICH schreibe, portiere, installiere
> einen Daemon, der weder LSB-Applikation ist, noch Bestandteil
> einer Distri ist, aber auf vorgeblich LSB-kompatiblem OSen laufen
> soll und will meinen Aufwand als Entwickler/Installer/SysAdmin
> minimieren. Dabei tritt die Frage auf: /usr/lib/lsb/* verwenden
> oder im Sumpf proprietärer Scripte versinken?
Na bitte, dann bist Du ein ISV, der versucht, seine(*) Software
LSB-compliant auf den Markt zu bringen.
(*) ob selbstgeschriebene Software oder GPL aus dem Netz setze ich
jetzt mal gleich.
> Mein Fazit ist: Die LSB-/usr/lib/lsb/*initd-Scripte helfen mir
> dabei nicht, da Sie immer noch Detailwissen über eine Vielzahl
> von Distributoren erforderen, deshalb faktisch in der Praxis,
> trotz LSB-Zertifizierung der Distris, nicht funktionieren.
Doch, sie helfen Dir.
http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB.html#INITSRCINSTRM
Da steht drin, wie Du sie verwendest. Wie die init.d-scripte
aussehen müssen, steht dirket drüber.
> Gegenfrage zur Gegenfrage: Warum verwendet SuSE die LSB-Scripte
> dann nicht? Es wäre nur konsequent und LSB-konform. Der LSB
> schreibt es zwar nicht vor, verbietet es aber auch nicht.
Eben, weil SuSE es selbst nicht muss. Das LSB-Zeug ist eine minimale
Voraussetzung, die eine Distribution mitbringen muss, damit ein ISV
(der keinerlei Verbindung zu jedwedem Distributor hat) Software auf
dem Markt bringen kann, die auf _jeder LSB-konformen_ Distrbution
ohne hacken läuft.
Sicherlich wäre es gut, wenn ein Distributor diese Tools auch
anwenden würde (dann würden alle install-scripte gleich aussehen),
aber das wäre in meinen Augen troztdem Bullshit, weil ein
Distributor einen eigenen Weg bei der Installation von Software
gehen kann, diesen eigenen für eigene Programme nutzen kann,
denselben aber für die ISVs zusammenpacken und in den
LSB-konforment scripts zusammenfasst.
> > Wo ist Dein Problem?
>
> Technisch betrachtet: Ein Detailproblem mit dem LSB (siehe oben).
>
> Hinzu kommt ein weitergehendes, vorwiegend politisches:
> Zertifizierungen und Standards sagen nichts über deren Qualität
> und Bedeutung aus. Sie müssen kritisch hinterfragt werden, da sie
> oftmals nur Marketinginstrument und Rechtfertigung sind sich
> einen Orden mehr auf die Brust zu heften oder einen Aufkleber
> mehr auf die Packung zu kleben.
>
> In diesem Sinne betrachte ich den LSB einerseits als
> wünschenswerte technische Initiative, anderseits aber auch als
> Marketinginstrument, das bekanntermassen nicht zuletzt von SuSE
> gepuscht wurde/wird.
>
> Ich nehme diesen "Orden", den sich SuSE und andere da an die
> Brust/Packung heften genauso zu Kenntnis, wie das GS, TÜV,
> ISO-900x, Demeter, Bioland, Fresenius, MIL, GMA-Zertifikate oder
> das Warentest oder ComputerBild Testurteil an anderen Produkten.
>
> Deshalb nehme ich mir die Freiheit und das Recht den LSB kritisch
> zu hinterfragen.
>
> Dabei komme ich momentan zum Ergebnis, dass der LSB zwar
> einerseits an einigen Stellen durchaus eine wünschenswerte
> Standardisierungen erreicht hat (Ob er möglicherweise aber nur
> offensichtliche, unvermeidbare Entwicklungen dokumentiert hat sei
> dahin gestellt), andererseits aber auch immer noch vieles offen
> und zu wünschen übrig lässt.
>
> Die /usr/lib/lsb/*initd Scripte gehören nach meinem momentanem
> Eindruck zu letzter Kategorie.
Ich verstehe nach Deinem letzten Posting immer noch nicht, was Dir
nicht gefällt. Ich habe allerdings den Eindruck, dass Du von "LSB"
mehr erwartest, als eigentlich definiert ist. Das wird wohl auch
das sein, was Thomas und Thorsten Dir sagen wollten, es nur nicht
direkt hingeschrieben haben.
Ich sehe die Funktionalität als add-on, damit es endlich Software
für Linux gib und nicht nur für RedHat (in den USA de-facto
Linux-Standard, ein anderes Linux gibt es gar nicht).
> Ralf
Stefan
--
Stefan Schmidt
jsj-hb at t-online dot de
On Thursday 31 October 2002 07:14, Ralf Corsepius wrote:
> Am Mit, 2002-10-30 um 10.26 schrieb Thorsten Kukuk:
> > On Wed, Oct 30, Ralf Corsepius wrote:
> > > Gegenfrage: Wie soll ich (distributionsübergreifend) einen
> > > Daemon installieren, wenn die Installation von
> > > init.d-Scripten durch die LSB-initd-Scripte nicht abgedeckt
> > > sind und Detail-Wissen über die proprietären Tools erfordern?
> >
> > Kommt darauf an, woher Du den Daemon hast. Wenn er Bestandteil
> > der Distribution ist, mit Distributions-Board-Mittel. Wenn er
> > eine LSB-Applikation ist, mit den entsprechenden LSB-Tools. Wo
> > ist das Problem?
>
> Wir reden aneinander vorbei: ICH schreibe, portiere, installiere
> einen Daemon, der weder LSB-Applikation ist, noch Bestandteil
> einer Distri ist, aber auf vorgeblich LSB-kompatiblem OSen laufen
> soll und will meinen Aufwand als Entwickler/Installer/SysAdmin
> minimieren. Dabei tritt die Frage auf: /usr/lib/lsb/* verwenden
> oder im Sumpf proprietärer Scripte versinken?
Na bitte, dann bist Du ein ISV, der versucht, seine(*) Software
LSB-compliant auf den Markt zu bringen.
(*) ob selbstgeschriebene Software oder GPL aus dem Netz setze ich
jetzt mal gleich.
> Mein Fazit ist: Die LSB-/usr/lib/lsb/*initd-Scripte helfen mir
> dabei nicht, da Sie immer noch Detailwissen über eine Vielzahl
> von Distributoren erforderen, deshalb faktisch in der Praxis,
> trotz LSB-Zertifizierung der Distris, nicht funktionieren.
Doch, sie helfen Dir.
http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB.html#INITSRCINSTRM
Da steht drin, wie Du sie verwendest. Wie die init.d-scripte
aussehen müssen, steht dirket drüber.
> Gegenfrage zur Gegenfrage: Warum verwendet SuSE die LSB-Scripte
> dann nicht? Es wäre nur konsequent und LSB-konform. Der LSB
> schreibt es zwar nicht vor, verbietet es aber auch nicht.
Eben, weil SuSE es selbst nicht muss. Das LSB-Zeug ist eine minimale
Voraussetzung, die eine Distribution mitbringen muss, damit ein ISV
(der keinerlei Verbindung zu jedwedem Distributor hat) Software auf
dem Markt bringen kann, die auf _jeder LSB-konformen_ Distrbution
ohne hacken läuft.
Sicherlich wäre es gut, wenn ein Distributor diese Tools auch
anwenden würde (dann würden alle install-scripte gleich aussehen),
aber das wäre in meinen Augen troztdem Bullshit, weil ein
Distributor einen eigenen Weg bei der Installation von Software
gehen kann, diesen eigenen für eigene Programme nutzen kann,
denselben aber für die ISVs zusammenpacken und in den
LSB-konforment scripts zusammenfasst.
> > Wo ist Dein Problem?
>
> Technisch betrachtet: Ein Detailproblem mit dem LSB (siehe oben).
>
> Hinzu kommt ein weitergehendes, vorwiegend politisches:
> Zertifizierungen und Standards sagen nichts über deren Qualität
> und Bedeutung aus. Sie müssen kritisch hinterfragt werden, da sie
> oftmals nur Marketinginstrument und Rechtfertigung sind sich
> einen Orden mehr auf die Brust zu heften oder einen Aufkleber
> mehr auf die Packung zu kleben.
>
> In diesem Sinne betrachte ich den LSB einerseits als
> wünschenswerte technische Initiative, anderseits aber auch als
> Marketinginstrument, das bekanntermassen nicht zuletzt von SuSE
> gepuscht wurde/wird.
>
> Ich nehme diesen "Orden", den sich SuSE und andere da an die
> Brust/Packung heften genauso zu Kenntnis, wie das GS, TÜV,
> ISO-900x, Demeter, Bioland, Fresenius, MIL, GMA-Zertifikate oder
> das Warentest oder ComputerBild Testurteil an anderen Produkten.
>
> Deshalb nehme ich mir die Freiheit und das Recht den LSB kritisch
> zu hinterfragen.
>
> Dabei komme ich momentan zum Ergebnis, dass der LSB zwar
> einerseits an einigen Stellen durchaus eine wünschenswerte
> Standardisierungen erreicht hat (Ob er möglicherweise aber nur
> offensichtliche, unvermeidbare Entwicklungen dokumentiert hat sei
> dahin gestellt), andererseits aber auch immer noch vieles offen
> und zu wünschen übrig lässt.
>
> Die /usr/lib/lsb/*initd Scripte gehören nach meinem momentanem
> Eindruck zu letzter Kategorie.
Ich verstehe nach Deinem letzten Posting immer noch nicht, was Dir
nicht gefällt. Ich habe allerdings den Eindruck, dass Du von "LSB"
mehr erwartest, als eigentlich definiert ist. Das wird wohl auch
das sein, was Thomas und Thorsten Dir sagen wollten, es nur nicht
direkt hingeschrieben haben.
Ich sehe die Funktionalität als add-on, damit es endlich Software
für Linux gib und nicht nur für RedHat (in den USA de-facto
Linux-Standard, ein anderes Linux gibt es gar nicht).
> Ralf
Stefan
--
Stefan Schmidt
jsj-hb at t-online dot de
| < Previous | Next > |