Cmmi Vereinheitlichung
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Veränderung (letzte Änderung) (Korrektur, Autor, Normalansicht)

Entfernt: 5,6d4
:BREIT Grins... :-) --- Ich hatte das mal in LinuxKritik angesprochen, Du erinnerst Dich? ;-) [Habe den Abschnitt jetzt mal hierher in den Diskussionsteil kopiert ] --ff


Entfernt: 16,53d13
[aus LinuxKritik]

Nun vielleicht als ganz kleines einfaches Beispiel [für Dinge die m.E. unnötig kompliziert sind unter Linux] ...

Wenn man unter Linux (Konsole) ein Programm "selbst" installieren will, *muss* man dazu ein bestimmtes Ritual ausführen...

Frag mich jetzt bitte nicht danach, wie das geht... Es besteht auf alle Fälle aus 3 geheiligten Worten [siehe CmmiMuster], die man hintereinander aussprechen muss... - Welche das im konkreten Fall sind, kann/muss man in einem beiliegenden INSTALL File (das praktisch immer dabei ist) nachlesen. (Irgendwo nach ca. 2-3 Seiten lesen, findet man dann den Hinweis auf die korrekten Zauberworte...)

Nun also: Was ich jetzt n i e verstanden habe, ist, weshalb man nicht einfach das INSTALL File ausführbar macht (also als ein Skript implementiert), das diese magischen Worte beinhaltet, und einfach (defaultmäßig) ausführt, wenn man es aufruft (ohne weitere Parameter anzugeben). Den Text des jetzigen INSTALL - Files würde ich dann auch lieber in einem README-File sehen - aber d a s hieße ja, mit einer "geheiligten Tradition" brechen!!!

Was wäre dadurch gewonnen???

Gewonnen wäre, dass man (auch als) Profi in 9 von 10 Fällen, zum Installieren nur noch INSTALL eintippt, und das entsprechende Programm / Bibliothek, etc. wird compiliert und "installiert". D a s ist es doch, was man in der Regel will... nein??? [Nein! Der wahre "Linuxjünger" will einen Ritus vollziehen, nicht einfach nur ein Programm installieren!]

Und in den wenigen Fällen, wo man eben selbst Hand an legen will (oder es beim Compilieren Probleme gibt), kann man INSTALL ja auch mit entsprechenden Parametern aufrufen - genauso wie das derzeit im Zusammenhang mit den anderen geheiligten "Worten" geschieht... // D a z u muss man dann ohnehin das README lesen.

:Anmerkung: Mit dem Hinweis: jeder Linux-User kann sich ja so ein INSTALL-File selber schreiben ist es nicht getan: denn welche Befehle jetzt genau aufgerufen werden müssen bei einem best. Programm-Paket variiert von Paket zu Paket... (Genauer... In 8 von 10 Fällen sind es zwar immer die selben 3 "Worte"... aber eben... in 2 Fällen, eben nicht! [Siehe CmmiAbweichungen] D.h. man kommt leider beim Installieren eines neuen, unbekannten Pakets nie um das Lesen des "INSTALL"-Textes herum...!!! :-((( ---> Man gönnt sich ja sonst nix, oder?!) // Wenn ein jeweils angepasstes INSTALL-File beiligt, brauche ich mich aber eben um so was gar NICHT zu kümmern!

Seufz... Mir persönlich erscheint das alles so logisch und "auf der Hand liegend" (!), dass es mich schon etwas ermüdet, so was immer wieder erklären zu müssen - ich mein jetzt nicht Dich Helmut..., sondern generell (die Linux-Gemeinde...) ... :-(((

Ich kann mich wirklich nicht daran erinnern, unter DOS, Windows, OS/2, ... je etwas anderes als SETUP oder INSTALL benötigt zu haben... // Nun ja... Linux ist eben... ARGL...!!! (Siehe LinuxKritik...)

--ff




Anmerkung: Helmut, gerade HIER sehe ich z.B. KEINE (unbedingte) "Notwendigkeit" einer Vereinheitlichung! Guck Dir mal meinen Vorschlag von oben an! Es würde doch genügen, wenn jedes zu installierende Paket SELBST weiß, wie es sich am besten installieren lässt... ;-)))

:Die einzige "Vereinheitlichung" hier sollte m.E. ein vorhandenes INSTALL (und SETUP) File sein, dass das jeweils korrekte Befehls-Muster in ausführbarer Form enthält.

Im Gegensatz dazu müsstest Du jetzt sozusagen eine "Datenbank" führen, wie was richtig installiert wird [bzw. wo es CmmiAbweichungen gibt]: bei einigen 10.000 Paketen [ev. auch noch unter Berücksichtigung versch. Versionen] ist der Aufwand nicht ohne, das immer AKTUELL zu halten... Ich persönlich halte das für den "falschen" Weg.

:Zudem erinnert mich das wieder an den Spruch: "Linux is only free, if your time is worthless..." :-/

--ff





Entfernt: 56,88d15
:Ich geh jetzt mal nur auf den ersten Punkt hier ein, auf den Rest erst später... ;-)

:"Wenn ich dich richtig verstehe, würdest du vorschlagen, dass jedes Paket ein SETUP-Programm enthalten soll" - nein nicht wirklich...

:Es ist ja so, dass JEDES Source-Paket eine Datei INSTALL besitzt in der lang und breit dies und das erklärt wird, und dann IRGENDWANN man auch gesagt wird, mit welchen "Standard-Befehlen" [also die geheiligten Worte] das Paket installiert wird.

:Mein Vorschlag ist nun, dass die Linux-Entwickler diesen langen Text in ein File README packen, und im File INSTALL (im wesentlichen) NUR NOCH die "korrekten" geheiligten Wort stehen lassen sollen.

:Genauer ein (Shell-)Skript halt, das mit INSTALL von der Shell aus aufgerufen werden kann [oder auch von der GUI über einen Dateimanager doppelgeklickt werden kann] und dann "das (jeweils) Richtige" macht... - NIEMAND weiß ja besser als der Entwickler selbst, was jeweils "das Richtige" ist... : und statt das in die Mitte eines langen Textfiles zu stellen, wo man es erst SELBER wieder herausholen darf... [---> LESEN macht Spaß!!! - Man hat ja sonst nix zu tun...] und erst noch wieder eingeben muss in die Shell..., sollte das schon in einem ausführbaren Skript "INSTALL" stehen...

:Natürlich darf das Skript auch komplexer sein..., so dass man eben auch bestimmte Parameter angeben kann. (...) --ff




"...das bedeutet aber einen Änderungsbedarf in jedem einzelnen Projekt." - Nun ja., das bringen grundlegendere Veränderungen halt nun mal so mit sich... ;-)

"Mein Ausgangspunkt wäre ein SETUP-Script, das sich vermutlich für den Standardfall leicht schreiben lässt, welches den Vorgang automatisiert."

: Dann doch lieber ein INSTALL-Script... (Auch wenn sich das mit der "INSTALL"-Text-Datei schlägt; schließlich geht es ums "Installieren"... ]

[[Code]#!/bin/sh
./configure "$@" \
&& make \
&& make install]

:Würde das funktionieren, sozusagen als 0-Version?

"Leider wird es nur in 80% der Fälle funktionieren, aber in diesen 80% Projekten, die "well-behaved" sind, wären in den Projekten keine Änderungen nötig." - Ja.

"Es ginge dann darum, mit minimalem Aufwand zu erkennen, welche Projekte nicht installiert werden können." - Ja.

:Dazu habe ich dann auch noch ne Idee... ;-) --ff


Entfernt: 91,92d17
...Würde das funktionieren, sozusagen als 0-Version?...


Entfernt: 169,170d93
:Kann man bestimmt... Man müsste sich halt mit dem Zip-Algorithmus beschäftigen... ;-) -ff


Hinzugefügt: 171a95


Verändert: 175c99
KategorieLinux---
KategorieLinux KategorieVereinheitlichung

Die Installation eines Source-Paketes unter Linux / Unix folgt meist dem CmmiMuster.

Als LinuxUmsteiger? dachte ich längere Zeit, dass dies ohnehin selbstverständlich wäre, bis ich dann doch regelmäßig auf Abweichungen gestossen bin.

Es wäre ganz praktisch, wenn dies in allen Projekten vereinheitlicht würde. Wenn dies nicht der Fall ist, könnte so ein Projekt zumindest eine Datei (z. B. NOTCMMI) enthalten, die entweder leer ist, oder die Motivation bzw. die Gründe für die Abweichung enthält. Ein Script könnte dann die Source-Installation weiter automatisieren. Das ist natürlich erst eine grobe Idee, die ausgearbeitet werden müsste.

Weiterer Aspekt: Die Vereinheitlichung sollte sich IMHO auch auf die Dekompression und die verwendeten Verzeichnisnamen erstrecken (auch hier gibt es Abweichungen, wo die erzeugten Verzeichnisse anderes heißen, als sich aus dem Dateinamen erwarten ließe). --hl

In jedem Fall braucht man die Information, welche Projekte vom CmmiMuster abweichen. Dazu könnte die Seite CmmiAbweichungen verwendet werden.


Diskussion

@ff: Wir sind uns im Ziel eines universellen SETUP einig, aber nicht im Weg dorthin. Wenn ich dich richtig verstehe, würdest du vorschlagen, dass jedes Paket ein SETUP-Programm enthalten soll - das bedeutet aber einen Änderungsbedarf in jedem einzelnen Projekt. Mein Ausgangspunkt wäre ein SETUP-Script, das sich vermutlich für den Standardfall leicht schreiben lässt, welches den Vorgang automatisiert. Leider wird es nur in 80% der Fälle funktionieren, aber in diesen 80% Projekten, die "well-behaved" sind, wären in den Projekten keine Änderungen nötig. Es ginge dann darum, mit minimalem Aufwand zu erkennen, welche Projekte nicht installiert werden können. Von der anderen Seite könnte man im 1. Schritt eine Kennzeichnung der Projekte vornehmen (NOTCMMI) und im 2. Schritt eine Etablierung von CmmiMuster vorschlagen oder selbst durchführen. Unlogisch? -- hl


Im Prinzip ja. Über die erweiternden Schritte

Könnte man ja dann diskutieren.

Natürlich müsste man auch prüfen, ob es so etwas nicht ohnehin schon gibt, bzw. was die einschlägigen Linux-Gruppen von so einer Vorgangsweise halten. -- hl

Ich hab mich da als LinuxAnfänger auch einmal an einem Perl-Script versucht, das ein oder mehrere Source-Packages dekomprimiert. Danach werden vereinfachte SymbolischeLinks auf die entstandenen Verzeichnisse gelegt (z.B. check -> check-0.8.2). Damit das mit dem Link funktioniert, muss allerdings der Name des Files mit dem Namen des komprimierten Verzeichnisses korrespondieren und die Versionsnummer im Verzeichnis mit Punkten geschrieben sein). Vielleicht ist davon etwas (zumindest von der Idee her) brauchbar.

Mal ein guter Ansatz. Hier ein Versuch das etwas zu systematisieren.

#! /usr/bin/perl
# Usage: unzip_package name*
use strict;
use warnings;

my $file;
my $dir;
my $name;

foreach $file (@ARGV) {
  if($file =~ m#/#) { # only current directory
    print STDERR "File '$file' ist nicht im lokalen Verzeichnis. ";
    print STDERR "Keine Bearbeitung.\n";
    next;
  }

  my $unzip;
  if($file =~ m/\.bz2$/) {
    $unzip = "j";
  } elsif ($file =~ m/(.*)\.gz$/) {
    $unzip = "z";
  } elsif ($file =~ m/(.*\[-_\.]tar)$/) {
    $unzip = "";
  } else {
    print STDERR "File '$file' hat keine bekannte Kompression (gzip, bzip). ";
    print STDERR "Keine Bearbeitung.\n";
    next;
  }

  # Neuer Filename
  $file = $1;

  $dir = $file;
  $dir =~ s/[-_\.]tar.*$//; # removes extensions
  $dir =~ s/(\d)_/$1./g; # change GNU 1_2_2 => 1.2.2
  $name = $dir;
  $name =~ s/-(\d.*)$//; # removes versions
  my $version = $1;
  print "Package: '$name'\tVersion: '$version'\n";
  mkdir $name;
  mkdir "$name/unpacked-$version";
  mkdir "$name/source";

  link $file, "$name/source/$file" && unlink $file 
       || die "Konnte $file nicht nach '$name/source/$file' verschieben: $!";

  chdir $name;
  
  system ("tar -C unpacked-$version xv" . $unzip . "f source/$file");

  unlink "current";
  symlink "unpacked-$version", "current" 
        || die "Konnte 'current' Symlink nicht legen: $!";

}

(Die Veränderungen habe ich mal nicht getestet, da ich keine Original Sourcen zur Verfügung habe. Kann vielleicht jemand eine Liste von Randfällen posten?)

Viel besser wäre es natürlich, wenn man in den gezippten File hineinschauen könnte, um den verwendeten Verzeichnisnamen dort herauszuholen. Aber in der Praxis hat das obige Script für mich schon ganz gute Dienste geleistet.

Siehe tar(1). Speziell --list.


Siehe auch: InstallationVonSource
KategorieLinux KategorieVereinheitlichung
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 3. Juni 2002 16:49 (diff))
Suchbegriff: gesucht wird
im Titel
im Text