Bâshgob
freies Radikal
Nicht das wir uns falsch verstehen:
Wir kennen uns nicht, und ich habe da ein echtes Vertrauensproblem mit binärer Fertigsoftware aus Quellen denen ich nicht vertraue weil ich sie nicht kenne.
Derartige Paketbeschreibungen
tragen ebenfalls nicht grade zur Vertrauensbildung bei, sorry.
Ausserdem vermisse ich die Quellpakete.
Wir kennen uns nicht, und ich habe da ein echtes Vertrauensproblem mit binärer Fertigsoftware aus Quellen denen ich nicht vertraue weil ich sie nicht kenne.
Derartige Paketbeschreibungen
Code:
christine: christine-0.1rc2-i486-1mn
christine:
christine:
christine: ... tja, ich weiss nicht einmal, was dieses Programm
christine: überhaupt macht ... :(
christine:
christine:
christine:
christine:
christine:
christine: Paket von W.Landgraf :) MONKEYNET Linux www.monkey.is-a-geek.net/tgztragen ebenfalls nicht grade zur Vertrauensbildung bei, sorry.
Ausserdem vermisse ich die Quellpakete.
W
werner1234
GESPERRT
Ich habe lange Pakete nur für mich selbst übersetzt, beginne jetzt aber, sie auch zu packen und zum download zur Verfügung zu stellen. Das soll langdauernd so bleiben. Das möchte ich potentiellen Benutzern mitteilen, damit es auch jemand weiß und benutzt
Sicherlich mag es am Anfang noch kleine Schönheitsfehler geben , aber die Pakete, die ich hier zum download tue, laufen zumindest bei mir. Denn nach dem Packen desinstalliere ich den übersetzten Quellcode und installiere ich das Paket.
Ich bin etwas sauer darüber, daß manche Autoren keine Beschreibung zu ihren Programmen tun, oder nur eine sehr kurze. Das gebe ich entsprechend weiter. Es ist Aufgabe der Programmierer und nicht der Packer, a) eine Anleitung zu schreiben, b) gröbste Programmierfehler zu verhindern, c) sich an gewissen Standards zu halten wie ./configure, make, make install -- andere Programme wandern bei mir sofort in den Müll. Wenn täglich 10-20 neue Programme im source-code kommen, ginge zeitlich gar nicht, mich mit jedem Programm noch weitergehend individuell zu beschäftigen (vielleicht mit Ausnahme einzelner wichtiger Programme) nur weil der Programmierer dazu zu schlampig ist.
Ein anderes Problem ist, daß ca. 50% der veröffentlichten Programme schon beim Übersetzen teils wegen trivialsten Fehlern scheitern (es gibt scheinbar Programmierer, die sie überhaupt nicht ausprobieren). Solche Fälle sind hier [anders als beim Quellcode] automatisch schon aussortiert - Paketbildung gescheitert - denn nur in Ausnahmefällen behebe ich Programmierfehler um ein Programm zum Übersetzen/packen/laufen zu bekommen. Die Programme als Paket .tgz haben also durchweg die selben Mängel wie ihr Quellcode .tar.bz2 . Das Einzige was ich mache ist, sie zu packen, und zu sehen ob sie auf meinem Rechner das compilieren und zumindest einen Startversuch überstehen; weitere Verbesserungen mache ich nicht.
Ganz allgemein gesprochen, sind die Pakete mit denselben Unsicherheiten behaftet, wie kostenlose Software überhaupt. Dazu gehört, daß viele Programme noch nicht fertig sind, Versions-Nr. 0. Man muß halt jedes Programm ausprobieren, und sich überlegen, ob es einem dienlich ist und ob man es benutzt.
Für Slackware gibt es iW nur die sites slacky.it und linuxpackages,net , die regelmäßig Pakete machen. Es wäre wünschenswert, wenn es mehrere wären; allgemein, wenn jeder der für sich selbst Quellcode übersetzt und einen Server hat, auch Pakete macht
Das Packen ist über das Übersetzen für den eigenen Bedarf hinaus nur ein wenig mehr. Dies mag im Vergleich zum Quellcode nützlich sein für wen a) wenig Zeit hat, b) nicht weiß wie man übersetzt, c) keinen Compiler/Kernel-source/headers installiert hat, d) [wie ich] nicht mehr das Chaos will, nebeneinander Pakete als auch Source-Code installiert zu haben. Wer meine Pakete nützlich findet, benutzt sie; wer nicht, nicht.
Aber noch folgender Hinweis: Ab Kernel 2.6.23-rc1-git5 wurde die thread-Behandlung und die virtuelle Speicherverwaltung durchgreifend geändert, woran verschiedene Programme (u.a. ndiswrapper, brtfs, obex) noch nicht angepaßt wurden und daher nicht ganz einwandtfrei funktionieren. Ich selbst benutze aber für meinen Server weiterhin den jeweils neusten Kernel (ggf. Überschrift meiner web-page anklicken --> info.php) sodaß diese momentanen Einschränkungen tragbar sind.
Sicherlich mag es am Anfang noch kleine Schönheitsfehler geben , aber die Pakete, die ich hier zum download tue, laufen zumindest bei mir. Denn nach dem Packen desinstalliere ich den übersetzten Quellcode und installiere ich das Paket.
Ich bin etwas sauer darüber, daß manche Autoren keine Beschreibung zu ihren Programmen tun, oder nur eine sehr kurze. Das gebe ich entsprechend weiter. Es ist Aufgabe der Programmierer und nicht der Packer, a) eine Anleitung zu schreiben, b) gröbste Programmierfehler zu verhindern, c) sich an gewissen Standards zu halten wie ./configure, make, make install -- andere Programme wandern bei mir sofort in den Müll. Wenn täglich 10-20 neue Programme im source-code kommen, ginge zeitlich gar nicht, mich mit jedem Programm noch weitergehend individuell zu beschäftigen (vielleicht mit Ausnahme einzelner wichtiger Programme) nur weil der Programmierer dazu zu schlampig ist.
Ein anderes Problem ist, daß ca. 50% der veröffentlichten Programme schon beim Übersetzen teils wegen trivialsten Fehlern scheitern (es gibt scheinbar Programmierer, die sie überhaupt nicht ausprobieren). Solche Fälle sind hier [anders als beim Quellcode] automatisch schon aussortiert - Paketbildung gescheitert - denn nur in Ausnahmefällen behebe ich Programmierfehler um ein Programm zum Übersetzen/packen/laufen zu bekommen. Die Programme als Paket .tgz haben also durchweg die selben Mängel wie ihr Quellcode .tar.bz2 . Das Einzige was ich mache ist, sie zu packen, und zu sehen ob sie auf meinem Rechner das compilieren und zumindest einen Startversuch überstehen; weitere Verbesserungen mache ich nicht.
Ganz allgemein gesprochen, sind die Pakete mit denselben Unsicherheiten behaftet, wie kostenlose Software überhaupt. Dazu gehört, daß viele Programme noch nicht fertig sind, Versions-Nr. 0. Man muß halt jedes Programm ausprobieren, und sich überlegen, ob es einem dienlich ist und ob man es benutzt.
Für Slackware gibt es iW nur die sites slacky.it und linuxpackages,net , die regelmäßig Pakete machen. Es wäre wünschenswert, wenn es mehrere wären; allgemein, wenn jeder der für sich selbst Quellcode übersetzt und einen Server hat, auch Pakete macht
Das Packen ist über das Übersetzen für den eigenen Bedarf hinaus nur ein wenig mehr. Dies mag im Vergleich zum Quellcode nützlich sein für wen a) wenig Zeit hat, b) nicht weiß wie man übersetzt, c) keinen Compiler/Kernel-source/headers installiert hat, d) [wie ich] nicht mehr das Chaos will, nebeneinander Pakete als auch Source-Code installiert zu haben. Wer meine Pakete nützlich findet, benutzt sie; wer nicht, nicht.
Aber noch folgender Hinweis: Ab Kernel 2.6.23-rc1-git5 wurde die thread-Behandlung und die virtuelle Speicherverwaltung durchgreifend geändert, woran verschiedene Programme (u.a. ndiswrapper, brtfs, obex) noch nicht angepaßt wurden und daher nicht ganz einwandtfrei funktionieren. Ich selbst benutze aber für meinen Server weiterhin den jeweils neusten Kernel (ggf. Überschrift meiner web-page anklicken --> info.php) sodaß diese momentanen Einschränkungen tragbar sind.
Zuletzt bearbeitet:
Bâshgob
freies Radikal
Du hast mein Posting nicht verstanden. Darum wiederhole ich meine Kernaussage nochmals:
Du solltest zudem mindestens angeben:
a.) die URL wo die Sourcen zu bekommen sind
b.) für welche Version du gebaut hast
c.) ggf. Abhängigkeiten zu Slackfremden Paketen
d.) ggf. mitgegegbene Buildoptionen
Ansonsten bleibe ich dabei: Ich vertraue fertiger Binärsoftware nicht, es sei denn das ich den Paketersteller kenne und diesem vertraue. Und so sollte das jeder Slacker sehen oder ggf. mit Problemen rechnen.
Und zum Stichwort Christine: Mir scheint, du baust wahllos irgendwelches Zeugs zusammen ohne dich damit auch nur im geringsten zu beschäftigen. Ok, es ist deine Zeit.
Falls es dich dennoch interessiert:
http://sourceforge.net/projects/christine/
Du solltest zudem mindestens angeben:
a.) die URL wo die Sourcen zu bekommen sind
b.) für welche Version du gebaut hast
c.) ggf. Abhängigkeiten zu Slackfremden Paketen
d.) ggf. mitgegegbene Buildoptionen
Ansonsten bleibe ich dabei: Ich vertraue fertiger Binärsoftware nicht, es sei denn das ich den Paketersteller kenne und diesem vertraue. Und so sollte das jeder Slacker sehen oder ggf. mit Problemen rechnen.
Und zum Stichwort Christine: Mir scheint, du baust wahllos irgendwelches Zeugs zusammen ohne dich damit auch nur im geringsten zu beschäftigen. Ok, es ist deine Zeit.
Falls es dich dennoch interessiert:
Code:
This is Christine a new Python, GTK+, GStreamer bassed media player. Is intended to be beautiful, usefull and fat free.http://sourceforge.net/projects/christine/
Zuletzt bearbeitet:
W
werner1234
GESPERRT
Gut, obwohl eigentlich nicht Aufgabe des Packers, beschäftige ich mich künftig etwas mehr mit den Programmen. Und wenn ein Programm größere Probleme haben sollte und mich ein Benutzer darauf hinweist, kann ich es auch ganz wegtun.
PS: Das Mühle-Programm gMühle was ich gerade hingetan habe, funktioniert, ich benutze es gerade
Den Source-Code der Programme hole ich von softpedia oder von einem Gentoo-site ftp://ftp.tu-clausthal.de/pub/linux/gentoo/distfiles . Die Versions-Nr steht im Paket-Name. Im Paket (ich glaube, irgendwo unter /doc habe ich das hingetan) befindet sich ein Skript *.SlackBuild, von mir, was ich für die Pakete benutze (tue ich je nach Programm etwas abändern). Ebenso eine Datei mit den Dependenzen (um die ich selbst mich aber nie kümmere). Im Gegensatz zu dem meisten anderen Paketen, die nur die .so und .la der Bibliotheken haben, ist bei mir auch das Format .a dabei, deshalb sind meine Pakete oft etwas größer
Gut, das christine habe ich jetzt auch ausprobiert, scheint zu funktionieren, man kann damit Musik abspielen, ob auch Filme weiß ich nicht/kann ich nicht testen da ich keinen Film habe; bei der nächsten version die ich davon packe, schreibe ich das rein Jeden Tag kommen in softpedia 50 ... 100 Programme; davon kann ich zwar ein Teil packen, sie aber nicht viel länger als 5 sek. ausprobieren.
Fast wie du schreibst, ich Übersetze/packe einige Programme, ohne sie aber selbst lange auszuprobieren. softpedia zBsp probiert ja auch nicht alle Programme aus (denn viele funktionieren nicht), sondern stellt sie zum download zur Verfügung. Sie zum download zu tun ist für diejenigen eine Hilfe, die alle neuen Programme haben wollen, sie aber nicht selbst compilieren können / wollen. Open source ist eben wie etwas im Müll suchen, das meiste taugt nichts und man probiert rum und pickt sich raus was man gebrauchen kann
Läßt sich denn mein Paket downloaden, installieren, und läuft das Programm zumindest ansatzweise - was es als source-code vor dem langwierigen Übersetzen/installieren nicht tut ? Dann ist ja meine Arbeit ok, es ist genau das was ich mache, nämlich packen und zum downloaden stellen, weniger es zu bewerten, Fortran-Fehler zu korrigieren usw.
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
Leider wieder solch ein Beispiel: Gerade habe ich ein Programm videotrans übersetzt. Source kam heute downloadbar bei softpedia. Ich habe es kopiert, weil die meisten Leute Programme für sound, video usw. mögen. Aber: KEINE BESCHREIBUNG VOM AUTOR DRIN. NACH dem Übersetzen/Packen sehe ich, daß es ein command-line tool ist, zBsp hat Aufrufe wie movie-to-dvd, movie-progress usw. Warum tut der Autor keine Beschreibung rein ? Erst NACH dem automatischen Übersetzen / Packen / Installieren kann ich es ausprobieren und sehen was es macht, für eine Beschreibung zu einer künftigen Version ..... Gut, wer Video-Sachen mag, kann es ja bei mir downloaden, und damit rumprobieren ob für ihn nützlich
PS: Das Mühle-Programm gMühle was ich gerade hingetan habe, funktioniert, ich benutze es gerade
Den Source-Code der Programme hole ich von softpedia oder von einem Gentoo-site ftp://ftp.tu-clausthal.de/pub/linux/gentoo/distfiles . Die Versions-Nr steht im Paket-Name. Im Paket (ich glaube, irgendwo unter /doc habe ich das hingetan) befindet sich ein Skript *.SlackBuild, von mir, was ich für die Pakete benutze (tue ich je nach Programm etwas abändern). Ebenso eine Datei mit den Dependenzen (um die ich selbst mich aber nie kümmere). Im Gegensatz zu dem meisten anderen Paketen, die nur die .so und .la der Bibliotheken haben, ist bei mir auch das Format .a dabei, deshalb sind meine Pakete oft etwas größer
Gut, das christine habe ich jetzt auch ausprobiert, scheint zu funktionieren, man kann damit Musik abspielen, ob auch Filme weiß ich nicht/kann ich nicht testen da ich keinen Film habe; bei der nächsten version die ich davon packe, schreibe ich das rein Jeden Tag kommen in softpedia 50 ... 100 Programme; davon kann ich zwar ein Teil packen, sie aber nicht viel länger als 5 sek. ausprobieren.
Fast wie du schreibst, ich Übersetze/packe einige Programme, ohne sie aber selbst lange auszuprobieren. softpedia zBsp probiert ja auch nicht alle Programme aus (denn viele funktionieren nicht), sondern stellt sie zum download zur Verfügung. Sie zum download zu tun ist für diejenigen eine Hilfe, die alle neuen Programme haben wollen, sie aber nicht selbst compilieren können / wollen. Open source ist eben wie etwas im Müll suchen, das meiste taugt nichts und man probiert rum und pickt sich raus was man gebrauchen kann
Läßt sich denn mein Paket downloaden, installieren, und läuft das Programm zumindest ansatzweise - was es als source-code vor dem langwierigen Übersetzen/installieren nicht tut ? Dann ist ja meine Arbeit ok, es ist genau das was ich mache, nämlich packen und zum downloaden stellen, weniger es zu bewerten, Fortran-Fehler zu korrigieren usw.
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
Leider wieder solch ein Beispiel: Gerade habe ich ein Programm videotrans übersetzt. Source kam heute downloadbar bei softpedia. Ich habe es kopiert, weil die meisten Leute Programme für sound, video usw. mögen. Aber: KEINE BESCHREIBUNG VOM AUTOR DRIN. NACH dem Übersetzen/Packen sehe ich, daß es ein command-line tool ist, zBsp hat Aufrufe wie movie-to-dvd, movie-progress usw. Warum tut der Autor keine Beschreibung rein ? Erst NACH dem automatischen Übersetzen / Packen / Installieren kann ich es ausprobieren und sehen was es macht, für eine Beschreibung zu einer künftigen Version ..... Gut, wer Video-Sachen mag, kann es ja bei mir downloaden, und damit rumprobieren ob für ihn nützlich
Zuletzt bearbeitet:
Bâshgob
freies Radikal
Du verschwendest deine Zeit.
Sinnlos, wie ich betonen möchte.
Sinnlos, wie ich betonen möchte.
W
werner1234
GESPERRT
Wie gesagt, compiliere ich schon seit langem jeden Tag viele Programme für meinen Rechner, und ist es wenig mehr, sie anschließend auch noch zu packen und irgendwo zum download hinzutun; das ist was ich jetzt beginne zu tun. Wer diese benutzen will, benutzt sie; wer nicht, nicht, ich wollte halt nur darauf hinweisen daß die Möglichkeit besteht. Ich selbst lade auch täglich alle Pakete von slacky.it oder linuxpackage down.
Zuletzt bearbeitet:
z00k
I love my slack! Do u?
Howdy,
so muss da jetzt auch mal was zu sagen. Finde es alles in Allem echt gut, wenn sich Leute fuer weitere Projekte wie linuxpackages oder slacky einzetzen, weil es solche einfach fuer Slackware viel zu wenig gibt. Trotzdem kann ich Bashgob's Kritik sehr gut nachvollziehen, weil ich es absolut genauso handhabe mit nicht vertrauten Packern und Packages.
Aber man muss sich auch eine Grenze setzen, wie weit man mit dieser Vertrauensschiene geht. Weil so gesehen kann man ja garkeinen Paketen, selbst denen von linuxpackages etc. vertrauen, da man sich nie absolut sicher sein kann, werd die Software gepackt hat.
Ich versuche ja soviel wie moeglichst selbst zu kompilieren, was bei manchen Applikationen natuerlich auch die gewuenschten Geschwindikeitsvorteile mit sich bringt.
Trotz alledem finde ich es gut, wenn sich Leute dran machen und weitere Slackware TGZ Portale aus dem Boden stampfen!
gReetZ
so muss da jetzt auch mal was zu sagen. Finde es alles in Allem echt gut, wenn sich Leute fuer weitere Projekte wie linuxpackages oder slacky einzetzen, weil es solche einfach fuer Slackware viel zu wenig gibt. Trotzdem kann ich Bashgob's Kritik sehr gut nachvollziehen, weil ich es absolut genauso handhabe mit nicht vertrauten Packern und Packages.
Aber man muss sich auch eine Grenze setzen, wie weit man mit dieser Vertrauensschiene geht. Weil so gesehen kann man ja garkeinen Paketen, selbst denen von linuxpackages etc. vertrauen, da man sich nie absolut sicher sein kann, werd die Software gepackt hat.
Ich versuche ja soviel wie moeglichst selbst zu kompilieren, was bei manchen Applikationen natuerlich auch die gewuenschten Geschwindikeitsvorteile mit sich bringt.
Trotz alledem finde ich es gut, wenn sich Leute dran machen und weitere Slackware TGZ Portale aus dem Boden stampfen!
gReetZ
W
werner1234
GESPERRT
Ja genau so sehe ich das auch
Jeder der Programme für sich übersetzt, sollte sie auch packen. Denn die Mehrarbeit ist gering. Man muss iW nur bei make install ein DESTDIR hinzufügen zu einem Ordner wo das Programm pseudo-installiert wird, und dort mkpackage anwenden.
Ich schreibe da nicht einmal 'zusätzlich'e Arbeit hinzu. Bei mir sind ca. 30.000 Programme (60 GB) installiert, davon nur ein kleiner Teil Pakete. Viele der Programme benutze ich nicht einmal. Aber oft installiere ich auch für andere Leute Linux -- und das macht man am besten, indem man seine eigene Installierung einfach kopiert. Und die Leute wollen dann andere Programme benutzen, die mich selbst vielleicht nicht interessieren. Jedenfalls installiere ich alles, was mir unter die Finger kommt.
Das Problem ist nun das Chaos, was entsteht, wenn man sowohl von Paketen als auch von source installiert. Das fängt bereits damit an, daß man dann ellenlange Listen vergleichen muß ob das Programm nicht schon in der anderen Art installiert ist. Ferner haben viele Programme kein make uninstall: am bekanntesten ist php - und damit haben viele Leute Probleme gerade weil noch irgandwo alte Installierungen im Rechner sind und gerade dann aufgerufen werden wenn es am meisten stört ... Pakete dagegen werden sauber uninstalliert.
Nach der Paketbildung wird die source-code-Installierung gelöscht (wo möglich) und das Paket installiert.
Deshalb will ich nach und nach die von source-installierten Programme alle zu Paketen machen. Das ist sehr viel Arbeit. Und da schadet es nichts, dann diese Pakete auch zur Benutzung durch Andere downloadbar zu machen. Denn automatisieren muß ich die Übersetzung/Paketbildung/Installierung/Uninstallierung des Source-Codes sowieso - etwa in der Form eines SlackBuild - und dabei ist es nur noch ein Tropfen mehr auch ein Paket zu bilden und zum download zu tun.
Denn auch ein Server läuft bei mir sowieso, schon lange. Da schadet es nichts, die Pakete in einen Ordner zu kopieren, von wo sie die Leute downloaden können.
Ich mache die Pakete so gut wie meinen Kenntnissen nach möglich, garantiere aber für nichts. Insbesondere beschränke ich mich auf die Arbeit, es zu übersetzen, zu packen, zum download zu tun. Wenn ein Programm nicht funktioniert, liegt es idR am Programm selbst und nicht am packen. Abgesehen von sehr seltenen Ausnahmefällen , durchsuche weder die Programme noch den Compiler nach Fehlern und korrigiere sie. Ebensowenig suche ich lange nach Beschreibungen, wenn sie nicht im Wurzelordner des .tar.gz sind. Beides ist Aufgabe der Programmierer, und dem Benutzer des Paketes entsteht dadurch keine grössere Arbeit als beim Quell-Code, ggf. Fehler des Programmes zu berichtigen oder Beschreibungen zu suchen. Bedenkt ferner, daß ich insbesondere neue Programme nicht schon einmal vor der Paketbildung gesondert übersetzt, getestet usw. habe, und/oder (außer bei Fehlern des Übersetzens/Packens selbst) nicht wiederhole. Bei Programmen mit groben Fehlern schlägt idR schon die Übersetzung/Paketbildung fehl. Und dabei sieht man oft wirklich die gröbsten Fehler - etwa einfache Syntax-Fehler im C-Code - sodaß einige Programmierer offenbar ihre Programme nicht einmal ausprobieren, da bin ich nicht bereit das zu korrigieren und solche Faulheit zu unterstützen. Das würde auch jede Automatisierung unmöglich machen. Nach Installierung des Programmes teste ich das Programm kurz, ob es wenigstens anspringt statt gleich abzustürzen. Dann kann man davon ausgehen, daß das Paket ebensogut funktioniert wie der source-code und eigene Übersetzung, meine Arbeit des Packens also OK ist.
Die Bewertung des Programmes selbst überlasse ich dann dem Benutzer . Hier bin ich einmal zugunsten des Programmierers nicht sehr zimperlich sondern der Auffassung, daß es bei open-source üblich ist , daß selbst unfertige Programme (die aber wenigstens 1x vom Autor ausprobiert sein und starten sollten) veröffentlicht, von Benutzern getestet, und durch Fehlermeldungen / Korrekturvorschläge an den Autor verbessert werden.
Jeder der Programme für sich übersetzt, sollte sie auch packen. Denn die Mehrarbeit ist gering. Man muss iW nur bei make install ein DESTDIR hinzufügen zu einem Ordner wo das Programm pseudo-installiert wird, und dort mkpackage anwenden.
Ich schreibe da nicht einmal 'zusätzlich'e Arbeit hinzu. Bei mir sind ca. 30.000 Programme (60 GB) installiert, davon nur ein kleiner Teil Pakete. Viele der Programme benutze ich nicht einmal. Aber oft installiere ich auch für andere Leute Linux -- und das macht man am besten, indem man seine eigene Installierung einfach kopiert. Und die Leute wollen dann andere Programme benutzen, die mich selbst vielleicht nicht interessieren. Jedenfalls installiere ich alles, was mir unter die Finger kommt.
Das Problem ist nun das Chaos, was entsteht, wenn man sowohl von Paketen als auch von source installiert. Das fängt bereits damit an, daß man dann ellenlange Listen vergleichen muß ob das Programm nicht schon in der anderen Art installiert ist. Ferner haben viele Programme kein make uninstall: am bekanntesten ist php - und damit haben viele Leute Probleme gerade weil noch irgandwo alte Installierungen im Rechner sind und gerade dann aufgerufen werden wenn es am meisten stört ... Pakete dagegen werden sauber uninstalliert.
Nach der Paketbildung wird die source-code-Installierung gelöscht (wo möglich) und das Paket installiert.
Deshalb will ich nach und nach die von source-installierten Programme alle zu Paketen machen. Das ist sehr viel Arbeit. Und da schadet es nichts, dann diese Pakete auch zur Benutzung durch Andere downloadbar zu machen. Denn automatisieren muß ich die Übersetzung/Paketbildung/Installierung/Uninstallierung des Source-Codes sowieso - etwa in der Form eines SlackBuild - und dabei ist es nur noch ein Tropfen mehr auch ein Paket zu bilden und zum download zu tun.
Denn auch ein Server läuft bei mir sowieso, schon lange. Da schadet es nichts, die Pakete in einen Ordner zu kopieren, von wo sie die Leute downloaden können.
Ich mache die Pakete so gut wie meinen Kenntnissen nach möglich, garantiere aber für nichts. Insbesondere beschränke ich mich auf die Arbeit, es zu übersetzen, zu packen, zum download zu tun. Wenn ein Programm nicht funktioniert, liegt es idR am Programm selbst und nicht am packen. Abgesehen von sehr seltenen Ausnahmefällen , durchsuche weder die Programme noch den Compiler nach Fehlern und korrigiere sie. Ebensowenig suche ich lange nach Beschreibungen, wenn sie nicht im Wurzelordner des .tar.gz sind. Beides ist Aufgabe der Programmierer, und dem Benutzer des Paketes entsteht dadurch keine grössere Arbeit als beim Quell-Code, ggf. Fehler des Programmes zu berichtigen oder Beschreibungen zu suchen. Bedenkt ferner, daß ich insbesondere neue Programme nicht schon einmal vor der Paketbildung gesondert übersetzt, getestet usw. habe, und/oder (außer bei Fehlern des Übersetzens/Packens selbst) nicht wiederhole. Bei Programmen mit groben Fehlern schlägt idR schon die Übersetzung/Paketbildung fehl. Und dabei sieht man oft wirklich die gröbsten Fehler - etwa einfache Syntax-Fehler im C-Code - sodaß einige Programmierer offenbar ihre Programme nicht einmal ausprobieren, da bin ich nicht bereit das zu korrigieren und solche Faulheit zu unterstützen. Das würde auch jede Automatisierung unmöglich machen. Nach Installierung des Programmes teste ich das Programm kurz, ob es wenigstens anspringt statt gleich abzustürzen. Dann kann man davon ausgehen, daß das Paket ebensogut funktioniert wie der source-code und eigene Übersetzung, meine Arbeit des Packens also OK ist.
Die Bewertung des Programmes selbst überlasse ich dann dem Benutzer . Hier bin ich einmal zugunsten des Programmierers nicht sehr zimperlich sondern der Auffassung, daß es bei open-source üblich ist , daß selbst unfertige Programme (die aber wenigstens 1x vom Autor ausprobiert sein und starten sollten) veröffentlicht, von Benutzern getestet, und durch Fehlermeldungen / Korrekturvorschläge an den Autor verbessert werden.
Zuletzt bearbeitet:
z00k
I love my slack! Do u?
naja, also das mache ich bestimmt nicht
Alle meine Systeme sind schoen schlank und schnell. Wozu das System mit unnoetiger Software gnadenlos ueberladen, wenn mans eh nicht braucht?
Ich nutze zB mein schon etwas aelteres Notebook noch beruflich zum Programmieren und da waere es absolut toedlich, dieses alte Maschinchen noch mit unnoetiger Software vollzustopfen.
gReetZ
W
werner1234
GESPERRT
Ich habe 12 Parttionen, 1 Minix, 11 Linux, Windows-nix. Davon ist Slackware mit Abstand was am schnellsten arbeitet, ganz fix, egal wieviel tausend Programme auf der Festplatte installiert sind. Und mein Rechner ist alt, 990 Mhz. Für die Geschwindigkeit ist nur relevant, was gleichzeitig läuft.
Was aber ein Problem ist, ist das Chaos. Insbesondere mehrfach installierte Programme. Bzgl. php ist das notorisch. Bei anderen Programmen merkt man es nur zufällig (So benutze ich Firefox 3. Ich habe mich gewundert, warum installierte plugins hinterher nie da sind. Danach hab' ich den Grund gefunden: Firefox 2 war auch irgandwo installiert, alle plugins usw. wurden dort installiert ... ) Dazu trägt ganz erheblich bei, daß Programme NICHT als Pakete installiert sind, incl. bei Erneuerung nicht sauber desinstalliert werden.
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
Hier noch eine ganz-kurz-Anleitung für wen wer auch Pakete machen / bereitstellen will - umso mehr Leute, desto besser.
Nachfolgende Vorgehensweise - halb-automatisch - ist an die Situation angepaßt, daß ein erheblicher Teil neuer Programme so schlampig programmiert ist, daß sie schon beim Übersetzen scheitern - oft wegen trivialster Fehler, und daran daß man halt auch versucht, falls auffindbar, eine Beschreibung einzubauen. So jedenfalls mache ich meine Pakete.
Bei diesem halbautomatischem Vorgehen macht man ./configure --prefix=/usr und #make erst einmal manuell, und erst wenn das klappt, ruft man .auto.SlackBuild auf. Nur bei Programme wo man weiß daß sie klappen, kann man alles mit dem Skript machen - dazu: das Skript in <Programmname/Version>.SlackBuild umbenennen ; in den download-Ordner /downloads/Programs tun wo auch <Programmname/Version>.tar.bz2 ist ; den Namen des Programmes am Anfang vom Skript reinschreiben , und bei Bedarf Parameter (etwa für ./configure ) im Skript ändern. Dann das skript ausführen. 95% der Programme mache ich jedoch auf die erstgenannte Art. Den Kernel immer auf die zweitgenannte Art, dazu den Namen des patches patch*.git ins skript schreiben und den patch ebenfalls in /downloads/Programs tun.
Das entsprechend abgewandelte Skript auto.SlackBuild findet sich unten. Aber es ist noch im Wandel; die neuste Version kann stets in meinen neusten Paketen gefunden werden. Obwohl es mehrfache Funktions-Moden hat, läßt man es am Anfang am besten so, und verwendet es exakt so wie nachfolgend beschrieben. Einzige Ausnahme: das Programm benutzt requiredbuilder , entweder man downläd das erst bei slacky.it, oder man setzt im Skript unten ein # davor um es zu desaktivieren Installiert sein muß #mc oder zumindest #mcedit, das geht auf und man muß/kann eine Paket-Beschreibung eintippen falls nicht schon vorhanden.
Also:
/ Ordner /downloads/Programs einrichten [nur beim 1. mal Benutzen nötig]
/ Ordner /pub einrichten, ggf. downloadbar für andere machen [ " ]
/ /usr/local/src einrichten (die gepackten sources werden wieder gelöscht) [ " ]
/ Das zu packende Programm .tar.bz2 entpacken nach /usr/local/src. Dazu am einfachsten in den #mc, zum .tar.bz2 , <ENTER>, und den dann sichtbaren Ordner auf die andere Seite kopieren
/ In den Ordner des entpackten Programmes gehen
/ # ./configure --prefix=/usr
/ # make
Man sieht nun, ob das Programm überhaupt erfolgreich compiliert, wenn nicht ---> Müll
/ Mein o.g. Skript auto.SlackBuild in den Ordner des entp. Programs kopieren
/ gucken ob beim Programm eine Beschreibung ist, ggf. lesen (da nachfolgend gefragt)
/ für ggf. zusätzliche Sachen die man ins Paket tun will (config-Dateien usw), einen Ordner "extra" machen (im Ordner mit dem source-code, also wo man gerade ist) und dort alles reinkopieren, der ist dann hinterher im Paket unter /doc/<Prog-Name>/extra, und/oder eine Datei README oder LIESMICH machen/erweitern
/ ./auto.SlackBuild # mein skript ausführen
Fertig, das Paket ist dann in /pub . Programm testen, ggf. Paket löschen wenns nichts taugt
update skript: verbesserte Behandlung von Ausnahmefällen (Programme bei deren source ./config oder DESTDIR=... nicht vorgesehen ist)
auto.SlackBuild :
Was aber ein Problem ist, ist das Chaos. Insbesondere mehrfach installierte Programme. Bzgl. php ist das notorisch. Bei anderen Programmen merkt man es nur zufällig (So benutze ich Firefox 3. Ich habe mich gewundert, warum installierte plugins hinterher nie da sind. Danach hab' ich den Grund gefunden: Firefox 2 war auch irgandwo installiert, alle plugins usw. wurden dort installiert ... ) Dazu trägt ganz erheblich bei, daß Programme NICHT als Pakete installiert sind, incl. bei Erneuerung nicht sauber desinstalliert werden.
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
Hier noch eine ganz-kurz-Anleitung für wen wer auch Pakete machen / bereitstellen will - umso mehr Leute, desto besser.
Nachfolgende Vorgehensweise - halb-automatisch - ist an die Situation angepaßt, daß ein erheblicher Teil neuer Programme so schlampig programmiert ist, daß sie schon beim Übersetzen scheitern - oft wegen trivialster Fehler, und daran daß man halt auch versucht, falls auffindbar, eine Beschreibung einzubauen. So jedenfalls mache ich meine Pakete.
Bei diesem halbautomatischem Vorgehen macht man ./configure --prefix=/usr und #make erst einmal manuell, und erst wenn das klappt, ruft man .auto.SlackBuild auf. Nur bei Programme wo man weiß daß sie klappen, kann man alles mit dem Skript machen - dazu: das Skript in <Programmname/Version>.SlackBuild umbenennen ; in den download-Ordner /downloads/Programs tun wo auch <Programmname/Version>.tar.bz2 ist ; den Namen des Programmes am Anfang vom Skript reinschreiben , und bei Bedarf Parameter (etwa für ./configure ) im Skript ändern. Dann das skript ausführen. 95% der Programme mache ich jedoch auf die erstgenannte Art. Den Kernel immer auf die zweitgenannte Art, dazu den Namen des patches patch*.git ins skript schreiben und den patch ebenfalls in /downloads/Programs tun.
Das entsprechend abgewandelte Skript auto.SlackBuild findet sich unten. Aber es ist noch im Wandel; die neuste Version kann stets in meinen neusten Paketen gefunden werden. Obwohl es mehrfache Funktions-Moden hat, läßt man es am Anfang am besten so, und verwendet es exakt so wie nachfolgend beschrieben. Einzige Ausnahme: das Programm benutzt requiredbuilder , entweder man downläd das erst bei slacky.it, oder man setzt im Skript unten ein # davor um es zu desaktivieren Installiert sein muß #mc oder zumindest #mcedit, das geht auf und man muß/kann eine Paket-Beschreibung eintippen falls nicht schon vorhanden.
Also:
/ Ordner /downloads/Programs einrichten [nur beim 1. mal Benutzen nötig]
/ Ordner /pub einrichten, ggf. downloadbar für andere machen [ " ]
/ /usr/local/src einrichten (die gepackten sources werden wieder gelöscht) [ " ]
/ Das zu packende Programm .tar.bz2 entpacken nach /usr/local/src. Dazu am einfachsten in den #mc, zum .tar.bz2 , <ENTER>, und den dann sichtbaren Ordner auf die andere Seite kopieren
/ In den Ordner des entpackten Programmes gehen
/ # ./configure --prefix=/usr
/ # make
Man sieht nun, ob das Programm überhaupt erfolgreich compiliert, wenn nicht ---> Müll
/ Mein o.g. Skript auto.SlackBuild in den Ordner des entp. Programs kopieren
/ gucken ob beim Programm eine Beschreibung ist, ggf. lesen (da nachfolgend gefragt)
/ für ggf. zusätzliche Sachen die man ins Paket tun will (config-Dateien usw), einen Ordner "extra" machen (im Ordner mit dem source-code, also wo man gerade ist) und dort alles reinkopieren, der ist dann hinterher im Paket unter /doc/<Prog-Name>/extra, und/oder eine Datei README oder LIESMICH machen/erweitern
/ ./auto.SlackBuild # mein skript ausführen
Fertig, das Paket ist dann in /pub . Programm testen, ggf. Paket löschen wenns nichts taugt
update skript: verbesserte Behandlung von Ausnahmefällen (Programme bei deren source ./config oder DESTDIR=... nicht vorgesehen ist)
auto.SlackBuild :
Code:
#! /bin/bash
#
### * 1) Einzugebende Definitionen (bleiben meist unverändert)
#
DISTRO="mn" # Neuste Version dieses Skriptes ist in den neusten Paketen
DISTRONOTE="Paket von W.Landgraf :) MONKEYNET Linux www.monkey.is-a-geek.net/tgz"
# Pakete kompatibel mit Slackware current
RDEV=/dev/hda2 ; RDEVFMT=ext4dev # nur für initrd nötig
#
#
# NOTMAKE=0: Normalfall: Programm /TBZ2DIR/ $NAME-$VERSION.tar.bz2 oder .gz ;
# ausführen: ./configure, #make, #make install, #make clean
# NOTMAKE!=0: manuell übersetzter Code ohne clean schon/noch in $SOURCEDIR vhd ist und nur gepackt wd soll, :
# kein Entpacken; kein Löschen des Ordners der Übersetzung, kein #make
# NOTMAKE=1: wie bei =0, starten von aussen, kein config/make, nur install
# NOTMAKE=2: aktuelles dir packen, falls angegeben, nach Paket $NAME-$VERSION-...
# Aber nicht nötig Name, Version (wird 'pwd' genommen), *** einfachstes Packen eines Programmes was schon erfolgreich
# manuell übersetzt / installiert wurde, und im selben Ordner nur gepackt werden soll, alle Namen werden an die des
# Ordners angepast, fehlende Dateien ersetzt
# *** Bei jeder manuellen Installierung von Programmen kann also nach dem #make install und vor dem #make clean
# vorliegendes skript in den aktuellen Ordner kopiert und ausgeführt werden, wobei NAME, VERSION, ZUSATZ leer bleiben
# und Fehlendes halbwegs sinnvoll automatisch ersetzt wird , NOTMAKE=2 setzen :)
# *** Das Kernel-Paket startet man dagegen am besten vom download-Ordner aus und füllt unten die genaue Version, patch aus;
# im download-Ordner sollten ausser linux ... .tar.bz2 auch patch ... .bz2, linux ... .SlackBuild und linux ... .slack-desc
# sein und wenigenstens ungefähr die Versions-Angabe enthalten sowie keine älteren Versionen mehr vhd sein
# Das zu bauende Programm muß als <name-version>.tar.bz2 oder .tar.gz im Ordner $TBZ2DIR (=/downloads/Programs normalerweise) sein,
# dazu eine Beschreibung in <>.slack-desc und vorliegende Datei entsprechend benannt und angepaßt <>.SlackBuild.
# Beim Kernel zusätzlich noch config-<version> (darin lokale_version geändert falls nicht -1mn)
# Falls ein patch vorhanden und anzuwenden, ferner noch patch-<version-patch> ; in diesem Fall m
# am Anfang sind dann Fragen zur Konfiguration des Kernels zu beantworten.
# Die den Bau von Kernel-Paketen betreffenden Punkte sind mit #### gezeichnet und so schnell auffindbar/aktivier- bzw desaktivierbar;
# zur Vermeidung verschiedener SlackBuild-Skripte und Fallunterscheidungen betrifft das nur unbedingt nötige Änderungen,
# Fehlermeldungen wegen sonstigen Nebensächlichkeiten ignorieren.
# Kernel-Paket enthält: /boot/ vmlinuz , config , System.map (<- #nm vmlinuz) : Kernel, Konfiguration, Symboltabelle ;
# /lib/modules: Kernel-Module, diejenigen Teile des Kernels, die nicht in vmlinuz enthalten sind, bei Bedarf mit
# #modprobe einzeln ladbar ; /usr/src/$NAMETGZ Quellprogramm des Kernels ; davon sind die Headers in
# /usr/src/$NAMETGZ/include die Verbindungen der Kernel-Funktionen nach ausen, durch Programme aufrufbar.
# Davon sind nur diejenigen nutzbar, die in der verwendeten Version von glibc und vom Kernel vorhanden waren als glibc
# übersetzt wurde -- diese sind in /usr/include enthalten, und insbesondere nur falls/dann bzw. unmittelbar bevor durch
# die aktuellen des Kernels in /usr/src/$NAMETGZ/include zu ersetzen wenn/womit glibc neu übersetzt wird
# Achtung: Der Paketname wird definitiv aus nachfolgenden Angaben zu NAMETGZ=$NAME-$VERSION$ZUSATZ-$ARCH-$BUILD gebildet;
# alle Dateien $NAME-$VERSION*.tgz oder .bz2 werden dazu zusammengesetzt und verwendet, ebenso egal der Name des darin
# enthaltenen Ordners !!!
# Nach Installierung der hier gebauten Pakete des Kernels nötig:
# * /etc/rc.d/rc.modules.new überprüfen, in ./rc.modules umwandeln ; * #rdev /boot/vmlinuz* /dev/hda1 ;
# * ggf. initrd bilden: #mkinitrd -c -k 2.6.22-rc7-git8-1mn -m jbd2:ext4dev:ext2:ext3:minix:reiserfs -r /dev/hda1 -f ext4dev ;
# * Eintrag in /etc/lilo.conf ; * #lilo ausführen/installieren ;
# * zur leichteren Benutzung ggf. in /boot links zu vmlinuz, System.map, config, initrd.gz ohne Version-Nr setzen
#
#
### ================ Paket zu bilden: Name, Version, Art, Hersteller
LEER=" "
LEER0=
# ****** Eingeben / ändern : *********
NAME=" " # %%% Name des Quelltextes .tar.bz2 Kernel: NAME=linux . Bei NAME=" " den aktuellen Ordner packen
VERSION="" # %%% [minimaler Teil von] Version des Quelltextes .tar.bz2 VERSION=2.6.22-rc7
ZUSATZ="" # -git7 # meist =" ": mit - im Namen .tgz gewünscht aber in NAME,VERSION der .tar.bz2 ggf nicht enthalten ZUSATZ=-git8
ARCH="i486" # %%% ARCH=i486
BUILD="1" # %%% BUILD=1mn #### !!! Achtung, für Kernel -$ARCH-$BUILD$DISTRO in config eingeben !!!
PATCH="patch" ; PATCHART="git" # Name des patches ind./generisch, nur relevant falls patch vhd. Kernel: patch / gif
# PATCH=$NAME ; PATCHART="dif" # für meiste Programme $NAME / dif
KOPIEREN=extra # einfaches Kopieren eines Ordners von $SOURCEDIR nach $DOC ( besonders bei $NOTMAKE >0 manuell hinzufügbar)
# !!! Mit/ohne / eingeben falls absolut bzw. relativ zu $SOURCEDIR
NOTMAKE=0 # siehe oben
HEADERS=0 # Nur relevant für Kernel: !=0 falls Kernel-Headers von /usr/src/linux-$... nach /usr/include hin installiert wd
KEEPSRC=0 # KEEPSRC=0,1,2 falls Übersetzung anschliessend löschen, clean, unverändert lassen
IFINSTALL=2 # IFINSTALL=0,1,2 falls gemachtes Paket installieren, updaten für Programme, Kernel NIE installieren/updaten
PUB=/pub # Wohin ggf. Kopie der Pakete sollen
TBZ2DIR=/downloads/Programs # Wo die downgeladenen / einzugebenden *.tar.bz2 oder *.tar.gz sind
TMP=/tmp/pkg # Baustelle, /tmp/pkg/$NAMETGZ/src Entpackung ; /TMP/pkg/NAMETGZ/pkg Package-Baum
PWDINIT=`pwd` # Von wo aus gestartet wurde
PREFIX0=/usr # --prefix für ./configure muss absolut sein, mit / beginnen !!
# ACHTUNG !! Dieses Skript fängt die meisten Nachlässigkeiten der Programmierer ab,
# aber in seltenen Fällen ist es nötig, unten Parameter für
# ./configure , make , make install abzuändern / hinzuzufügen
### nicht ändern:
NAME1=`expr substr $NAME 1 1` # <-- This is correct !!! That here comes a expr error reclamation, shows notten else
echo "Name fängt an mit:" $NAME1 # than what a shit is bash, and Linux generally :( Only progs from drugged jonkys
if test $NAME1 = $LEER ; then # <-- Same thing here 'unary operator expected'
echo "*** Name des Paketes wird gebildet aus PWD initial: " $PWDINIT
NOTMAKE=2 ; # Falls kein Name, aktuelles dir packen, seinen Namen übernehmen
NV=${PWDINIT##*/} # kpl. Name alles nach letztem /
NAME=${NV%%-[0,1-9]*}
VERSION=${NV#$NAME-} # Bei Programmen: ZUSATZ, ARCH, DISTRO im Namen des Ordners NICHT enthalten, oben angeben !!
fi
KERNEL=0 ### ================ Ob Kernel (insgesamt/aufgeteilt) oder Programm zu packen ??
if test $NAME = linux ; then KERNEL=1 ; fi ;
if test $NAME = kernel ; then KERNEL=2 ; fi ;
if test $KERNEL != 0 ; then
if test $NAME1 = $LEER ; then
VERSIONTGZ=$VERSION
REST=${VERSIONTGZ%-[0,1-9]*}
BUILDDISTRO=${VERSIONTGZ#$REST-} # 1mn Sollte mind. die Nr. vhd sein
BUILD=${BUILDDISTRO%%[a-z,A-Z]*}
DISTRO=${BUILDDISTRO#$BUILD} # nicht nötig. zBsp mn
VERSION=${REST%-[a-z,A-Z]*} # VERSION enthält hier bereits Zusätze wie -rc2 , -git7, also ZUSATZ=""
ARCH=${REST#$VERSION-} # Nötig. Später einbauen: Falls nicht arch oder iX86, wird durch i486 ersetzt
ZUSATZ=""
fi
fi
if test $NAME1 = $LEER ; then
echo "*** aus PWD gebildet: NAME: " $NAME " , VERSION: " $VERSION
echo "*** PWD(Kernel)/Vorgabe(Progs): ZUSATZ: " $ZUSATZ " , ARCH: " $ARCH " , BUILD: " $BUILD " , DISTRO: " $DISTRO
fi
NV=$NAME-$VERSION # [minim. Teilmenge von] Name+Version des .tar.bz2 NV=linux-2.6.22-rc7
VERSIONTGZ=$VERSION$ZUSATZ-$ARCH-$BUILD$DISTRO # Version des Paketes VERSIONTGZ=2.6.22-rc7-git8-i486-1mn
NAMETGZ=$NV$ZUSATZ-$ARCH-$BUILD$DISTRO # kpl. Name des Paketes NAMETGZ=linux-2.6.22-rc7-git8-i486-1mn
PATCHTOTAL=$PATCH-$VERSION*$PATCHART* # normal bei Kernel: $PATCH=patch / $PATCHART=git , sonst =$NAME / diff
if test $NOTMAKE = 2 ; then SOURCEDIR=$PWDINIT ; SRCSDIR=${SOURCEDIR%/*} ; # NAME.NE."" auch anders als subdir wählbar
else # if test $NOTMAKE != 2 ; then
if test $KERNEL != 0 ; then SRCSDIR=/usr/src ; SOURCEDIR=$SRCSDIR/$NAMETGZ
else SRCSDIR=/usr/local/src ; SOURCEDIR=$SRCSDIR/$NV$ZUSATZ ; fi;
fi
TMP=$TMP/$NAMETGZ # nötig , da falls mehrere Programme laufen, das letzte alles der anderen löscht
rm -r $TMP 2> /dev/zero
mkdir -p $TMP
echo "0 TMP: " $TMP > $TMP/test.test
ls $TMP >> $TMP/test.test
# chown -R root:root $SOURCEDIR
### Anweisungen für Skript der Installierung /install/doinst.sh Je nach Programm ausfüllen !!
#if test $KERNEL = 0 ; then # Für Programme (nicht Kernel) nur dies:
cat << EOF > $TMP/doinst.sh
#
EOF
#fi
if test $KERNEL != 0 ; then # Für Paket linux (Kernel):
VZ=$VERSION$ZUSATZ ; VZ=${VZ//./$LEER0} ; VZ=${VZ//-/$LEER0} # Version-Nr ohne - und .
VZTXT=$VZ'txt' ; VZIRD=$VZ'ird' # again, because bash is soooo stupid and unlogical, one cannot write this direcly, below
echo ' # root-Gerät/Partition bei der Installierung abfragen --> RDEV0/RDEV
RDEVX=`rdev`
RDEV=${RDEVX%%" "/} # root-device wohin Kernel oder System installiert wird
RDEV0=${RDEVX%%[0,1-9]*" "/} # zugehöriges Gerät
RDEVFMT=ext4dev # ggf. ersetzen durch $RDEVFMT oder Format von $RDEV bei Installierung abfragen
' >> $TMP/doinst.sh
cat << EOF >> $TMP/doinst.sh
#
echo " boot-Gerät: " \$RDEV0 " boot/root-Partition: " \$RDEV
rdev /boot/vmlinuz-$VERSIONTGZ \$RDEV
echo "#
# hinzugefügt vom MonkeynetLinux Install-Programm
image = /boot/vmlinuz-$VERSIONTGZ
root = \$RDEV
label = \"$VZ\"
read-only
vga=791
append=\"4 root=\$RDEV devfs=nomount noapic nolapic acpi=ht\"
image = /boot/vmlinuz-$VERSIONTGZ
root = \$RDEV
label = \"$VZTXT\" # hoffentlich wird das nicht zu lang ...
read-only
vga=0
append=\"3 root=\$RDEV devfs=nomount noapic nolapic acpi=ht\"
#
" >> /etc/lilo.conf # lilo config-File machen
lilo -b \$RDEV0 # lilo installieren
cp -f /boot/map /boot/map-$VERSIONTGZ
echo " "
echo "**** Kernel $VERSIONTGZ installiert nach " \$RDEV " , LILO nach " \$RDEV0 ":) ****"
echo "Nicht vergessen /etc/rc.d/rc.modules[.neu] zu überprüfen"
echo " und ggf. in /etc/lilo.conf automatischen Zusatz umbenennen/umsortieren"
echo " und #lilo nochmal laufen lassen"
echo "ggf. initrd bilden: #mkinitrd -c -k $VERSIONTGZ "
echo " -m jbd2:ext4dev:ext2:ext3:minix:reiserfs -r " \$RDEV " -f " \$RDEVFMT
echo " danach Eintrag in /etc/lilo.conf: initrd=initrd.gz ; und #lilo ausführen"
echo "Nachfolgend wird dies versucht, separat für den Fall des Fehlschlages"
echo "Nach dem booten in diesen Kernel können ältere Pakete linux oder kernel desinstalliert"
echo " werden. Ferner versionsabhängige Programme neu installieren / übersetzen, "
echo " u.a. fuse, ntfs-ng3, btrfs, linux-wlan, ndiswrapper usw; "
echo " und #linux_logo > /etc/issue ; #depmod -a ; #ldconfig ausführen "
echo "****"
#
rdev /boot/initrd.gz-$VERSIONTGZ \$RDEV # initrd von anderem Rechner funktioniert idR nicht, nur für denselben wenn mkinitrd fehlschlägt
mkinitrd -c -k $VERSIONTGZ -o /boot/initrd.gz-$VERSIONTGZ -m jbd2:ext4dev:ext2:ext3:minix:reiserfs -r \$RDEV -f \$RDEVFMT
echo "#
image = /boot/vmlinuz-$VERSIONTGZ
root = \$RDEV
initrd = /boot/initrd.gz-$VERSIONTGZ
label = \"$VZIRD\"
read-only
vga=0
append=\"3 root=\$RDEV devfs=nomount noapic nolapic acpi=ht\"
#
" >> /etc/lilo.conf
lilo -b \$RDEV0 # lilo installieren
cp -f /boot/map /boot/map-$VERSIONTGZ
sync
EOF
if test $HEADERS != 0 ; then # Falls Kernel-Headers
cat << EOF >> $TMP/doinst.sh
#
echo "*** Die Kernel-Headers wurden von $SOURCEDIR/include nach /usr/include verschoben !!!"
echo "*** Das macht die Verwendung (ggf. sofortige Erzeugung) einer glibc mit diesem Kernel erforderlich !!!"
#
EOF
else
cat << EOF >> $TMP/doinst.sh
#
echo "*** Die Kernel-Headers wurden NICHT von $SOURCEDIR/include nach /usr/include kopiert !!!"
echo "*** Falls Programme übersetzt werden sollen, möglichst kernel-headers derjenigen Version des Systemes installieren"
echo "*** welche zur Übersetzung der zZt installierten glibc verwendet worden waren; bzw. ein bei der bisherigen Installierung"
echo "*** vhd. Paket Kernel-Headers nicht desinstallieren. Falls unklar/nicht vhd, die neu "
echo "*** installierten header wie beschrieben kopieren, aber das macht die Verwendung (ggf. sofortige Erzeugung) einer "
echo "*** glibc mit diesem Kernel erforderlich !!!"
#
EOF
fi # headers
fi # kernel !=0
echo "1 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
# ******** (individuell zu ändernde Teile dieses Skriptes beendet) **********
###
echo "*** zu erstellendes Paket: " $NAMETGZ.tgz
echo "*** Quelle: ifKernel: " $KERNEL " Headers (relevant nur für Kernel): " $HEADERS " ifNotMAKE: " $NOTMAKE
echo " alle Quell-Ordner in: " $SRCSDIR " dieser Quellordner: " $SOURCEDIR
echo " Name: " $NAME " Version: " $VERSION " Zusatz: " $ZUSATZ
echo " Arch: " $ARCH " BUILD: " $BUILD " DISTRO: " $DISTRO
echo "*** Install-Shell: "
cat $TMP/doinst.sh
echo "***"
#echo -e "Packen: \c"
#if test $KERNEL != 0 ; then
# echo "Kernel"
# if test $HEADERS = 0 ; then echo -e "Keine \c" ; else echo -e "Doch \c" ; fi ;
# echo "Kernel-Headers von /usr/src/"$NAMETGZ " nach /usr/include installieren und Verweis zu Erstem"
#else
# echo "Programm"
#fi
### ================ Ausgabe der zu bearbeitenden Dateien
# noch einbauen, test für $NOTMAKE !=0 ob $SOURCEDIR da, wenn nicht, NOTMAKE=0 setzen
if test $NOTMAKE != 0 ; then
echo "* schon entpackter / vorhandener Quellkode in: " $SOURCEDIR " verwenden "
fi
if test $NOTMAKE = 0 ; then rm -r $SOURCEDIR 2> /dev/zero ; mkdir -p $SOURCEDIR # $SOURCEDIR nicht löschen bei $NOTMAKE>0
echo "entpackter Quellkode kommt in: " $SOURCEDIR
echo "insgesamt gefundene evtl. relevante Eingabedateien: "
ls -l $TBZ2DIR/$NAME-$VERSION*
echo "* davon verwendeter Quellcode: letzter von: "
ls -l $TBZ2DIR/$NV*.tar.*
echo "* anzuwendende patchs:"
ls -l $TBZ2DIR/$PATCHTOTAL
# if test $KERNEL = 0 ; then
# echo "* Konfiguration für make:" $CONFIGURE
# fi
fi
if test $KERNEL != 0 ; then
if test $HEADERS != 0 ; then
echo "*** WARNUNG !! Die vorhandenen Kernel-Headers werden durch neue ersetzt !!!"
echo "*** Das macht die Installierung oder Übersetzung der glibc für diesen Kernel nötig !!!"
fi
fi
TGZ=$TBZ2DIR/$NAMETGZ.tgz # Paket kommt in download-Ordner wo auch das .tar.bz2 ist
rm -f $TGZ 2> /dev/zero # Alte Pakete ggf. löschen
echo "* zu erstellendes Paket: " $TGZ
echo "2 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
#
# 2) Vorbereitungen
#
echo "Baustelle Quell-Entpackung / Paketbildung: " $TMP
# mkdir -p $TMP ... aber als schon vhd angenommen, bzw durch nachfolgende rekursive Anweisung erstellt
PKG=$TMP/pkg # wo Paket-Struktur gebaut wird
#rm -r $PKG 2> /dev/zero # oben: Löschen von altem Kram jedenfalls nötig; manuelle Übersetzung ohne clean ggf in $SOURCEDIR
echo "* Struktur vom Paket kommt in Ordner: " $PKG
# Bei den meisten Programmen macht #make alle nötigen Ordner - bei manchen aber nicht ... :( :
mkdir -p $PKG/usr $PKG/usr/bin $PKG/usr/sbin $PKG/usr/man/man5 $PKG/usr/man/man8 # ggf $PKG/usr durch $PREFIX ersetzen
#rm -r $TMP/src 2> /dev/zero
mkdir -p $TMP/src # dorthin vorläufiges Entpacken, da Fallunterscheidung jenachdem wie Ordner im .tar.bz2 benannt
echo "vorläufige Entpackung von Programm in: " $TMP/src
echo "3 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
if test $KERNEL = 0 ; then
### ================= HIER GGF ANPASSEN !!!!! =====================
# für make: Manche Programme verstehen kein DESTDIR= , andere haben kein ./configure , daher PREFIX etc explizit vorgeben
# Diese Parameter müssen für ggf. vhd. ./configure UND make , make install vhd sein , also vor beides setzen !!!
#DESTDIR0=$PKG # für make
#PREFIX0=[/usr] # gewählte Vorgabe siehe oben
#PREFIX=$PKG$PREFIX0 ; DESTDIR0=[irgendwas] # falls #make DESTDIR nicht kennt , dann DESTDIR0=beliebig
#PREFIX=[irgendwas] ; DESTDIR0=$PKG$PREFIX0 # falls kein ./config vhd, dann PREFIX=beliebig
#PREFIX=$PREFIX0 ; DESTDIR0=$PKG # Normalfall . Akkumulativ: PREFIX=PREFIX0 , DESTDIR0=PKG
PREFIX=$PREFIX0 ; DESTDIR0=$PKG
EPREFIX=$PREFIX # meist überflüssig
OLDINCLUDEDIR=$PREFIX/include
CFLAGS="-march=$ARCH -mcpu=$ARCH" # \
CONFIGURE=" ./configure --prefix=$PREFIX " # falls NICHT Kernel und NOTMAKE=0 ergänzen durch geeignete Parameter
fi # Bei Slackware ist idR --prefix=/usr etc
## 3) Arbeit
if test $NOTMAKE = 0 ; then
### ================ a) Entpacken
echo "Entpacken nach: " $TMP " , vorläufig nach: " $TMP/src
tar -C $TMP/src -zxf $TBZ2DIR/$NV*.tar.gz 2> /dev/zero # /downloads/Programs/prg-1.0.tar.gz --> /tmp/prg-1.0
tar -C $TMP/src -jxf $TBZ2DIR/$NV*.tar.bz2 2> /dev/zero # entweder .gz oder .bz2 , daher beide lassen
# Quellcode ist jetzt entpackt in: $TMP/src ohne Ordner; $TMP/src/NAME* ; oder sonstwo; nach besser definierten Ort $SOURCEDIR verschieben:
mv -f $TMP/src/$NAME*/* $SOURCEDIR # sehr wichtig , falls Version-Nr fehlt, oder Name Paket anders als Ordner
rm -r $TMP/src/$NAME*
mv -f $TMP/src/* $SOURCEDIR # Quellcode zum definitiven Platz verschieben
cd $SOURCEDIR # cd /downloads/Programs/SlackBuild/prg-1.0 , --> .../pkg prg-1.0-i486-1mn.tgz erzeugen
echo "in Ordner vom entpackten Quellkode gehen : " $SOURCEDIR
# konfig holen
if test $KERNEL != 0 ; then
cp /boot/config $SOURCEDIR/.config #### falls kein anderes config vhd , das vom lfnd. System verwenden
cp $TBZ2DIR/config-$VERSION* $SOURCEDIR/.config #### ./config muss schon auf neuen Kernel angepasst sein, in .bz2 -Ordner
cp /boot/config-$VERSION* $SOURCEDIR/.config
fi
# patch kopieren, patchen
cp $TBZ2DIR/$PATCHTOTAL $SOURCEDIR
bzip2 -d $SOURCEDIR/$PATCHTOTAL.bz2 # Anwendung aller patchs
echo "patch : " $PATCHTOTAL " Ordner " $SOURCEDIR
echo "patch : patch -p 1 <" $SOURCEDIR/$PATCHTOTAL " in Ordner: " $SOURCEDIR
touch .gitignore # da oft nicht vhd. aber vom patch gesucht wird
patch -p 1 < $SOURCEDIR/$PATCHTOTAL
rm -f $PATCHTOTAL # darf bei mehrfacher Verwendung des Skriptes/Quellcodes nicht bleiben
# zu verwendender Quellcode/Konfig listen
echo " Ordner mit Quelldaten, mit patchs,konfig vor Übersetzung mit make : "
ls -l
### ================== b) Übersetzen
echo "konfigurieren, make machen, make install nach .../pkg. "
if test $KERNEL = 0 ; then
echo " CONFIGURE :" $CONFIGURE
sleep 15
$CONFIGURE
echo "*** Übersetzen ..."
make
else
echo "*** Neuigkeiten im Kernel -- bitte konfigurieren: "
make silentoldconfig #### Kernel.
echo "*** Bitte Konfiguration überprüfen - incl. (genau) Name/Patch, lokale Bezeichng - , ggf, korrigieren !!!"
sleep 9
make menuconfig #### Kernel, nochmals Chance die Einstellungen zu überprüfen, weg falls batch-Betrieb
echo "*** Übersetzen (dauert !!!) ..."
make -kiB ### Kernel mit Option -kiB, übersetzen selbst wenn einige neue Module Probleme haben ...
make htmldocs #### Kernel
fi # test $KERNEL
#cd $SOURCEDIR
echo " Ordner mit Quelldaten, Übersetzung mit make gerade gemacht: "
ls -l
fi # test $NOTMAKE
echo "4 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
### =================== c) installieren nach $PKG
echo "*** Installieren / make install nach " $PKG
cd $SOURCEDIR
# Programme
if test $KERNEL = 0 ; then
echo " PREFIX: " $PREFIX " , EPREFIX: " $EPREFIX
echo " DESTDIR: " $DESTDIR0
sleep 15
#make install # ausreichend falls DESTDIR= oben vorgegeben
make DESTDIR=$DESTDIR0 install # PROGRAMME: DESTDIR oben vorgeben entweder/oder: DESTDIR= ; ROOT= ; prefix=
# DESTDIR muss explizit angegeben werden, ist nicht als Umgebungsvariable bekannt
make clean
mkdir -p $PKG/etc/rc.d
mv $PKG/etc/init.d/* $PKG/etc/rc.d/rc.$NAME.new
rm -r $PKG/etc/init.d
fi
# Kernel
if test $KERNEL != 0 ; then
make -kiB install # KERNEL: normal installieren, evtl -kiB (#nm vmlinuz System.map)
make -kiB modules_install # KERNEL: Module installieren, evtl -kiB
if test $HEADERS != 0 ; then
make headers_install_all # Normalerweise manuell und nur sobald glibc übersetzt wird !!!!!
make headers_check_all
fi
# initrd idR nicht transportabel, bei grosem Kernel auch nicht nötig, und wird bei install gemacht
make clean
rm .config.old
cp -f $SOURCEDIR/.config /boot/config
cp -f /boot/config /boot/config-$VERSIONTGZ
cp -f /boot/vmlinuz /boot/vmlinuz-$VERSIONTGZ
cp -f /boot/System.map /boot/System.map-$VERSIONTGZ
echo "5 TMP vor mkinitrd: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
mkinitrd -c -k $VERSIONTGZ -m jbd2:ext4dev:ext2:ext3:minix:reiserfs -r $RDEV -f $RDEVFMT
cp -f /boot/initrd.gz /boot/initrd.gz-$VERSIONTGZ
echo "5 TMP nach mkinitrd: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
# fi ; if test $KERNEL != 0 ; then
# Kernel: kopieren von Source, Kernel, Modules, rc-Skripts nach PKG=$TMP/pkg
echo "*** Vorbereitung vom Packen: "
echo "KERNEL SOURCE: kopieren: $SOURCEDIR nach $PKG$SRCSDIR"
echo " und link: ln -sf $SOURCEDIR $PKG$SRCSDIR/linux" # nötig
echo "$SOURCEDIR : "
ls $SOURCEDIR
mkdir -p $PKG$SRCSDIR #### Kernel: Quell-Kode $PKG/usr/src machen
cp -a $SOURCEDIR $PKG$SRCSDIR #### "
echo "ln -sf $SOURCEDIR $PKG$SRCSDIR/linux"
ln -sf $SOURCEDIR $PKG$SRCSDIR/linux #### link von /usr/src/linux-<Version> nach /usr/src/linux machen
ln -sf $SOURCEDIR $PKG$SRCSDIR/$NAME-$VERSION$ZUSATZ #### link nach Version ohne Zusätze
echo "KERNEL MODULES: kopieren: /lib/modules/*$VERSIONTGZ* nach $PKG/lib/modules "
echo "/lib/modules/*$VERSIONTGZ* : "
ls /lib/modules/*$VERSIONTGZ*
mkdir -p $PKG/lib/modules #### Kernel: Module machen
cp -a /lib/modules/$VERSIONTGZ $PKG/lib/modules
echo "KERNEL MODULES KONFIG: kopieren: /etc/rc.d/rc.modules nach $PKG/etc/rc.d/rc.modules.new"
echo "/etc/rc.d/rc.modules : "
ls /etc/rc.d/rc.modules
mkdir -p $PKG/etc/rc.d #### Kernel: /etc/rc.d/rc.modules kopieren
cp /etc/rc.d/rc.modules $PKG/etc/rc.d/rc.modules.new
ln -sf /etc/rc.d/rc.modules $PKG/etc/rc.d/rc.modules-$VERSIONTGZ
echo "KERNEL PROGRAMM: kopieren: /boot/*$VERSIONTGZ* nach $PKG/boot"
echo "/boot/*$VERSIONTGZ* : "
ls /boot/*$VERSIONTGZ*
mkdir -p $PKG/boot #### Kernel: ausführbarer Kernel in /boot kopieren
cp /boot/*$VERSIONTGZ* $PKG/boot #### alle Kernel mit gl.Version kopieren da ggf. mehrere gebaut wurden
if test $HEADERS != 0 ; then
echo "KERNEL HEADER: move $PKG$SOURCEDIR/include nach $PKG$SRCSDIR/usr "
echo " und link ln -sf /usr/include $PKG$SOURCEDIR/include "
echo "$PKG$SOURCEDIR/include :"
ls $PKG$SOURCEDIR/include
#mkdir -p $PKG/usr #### Kernel: header kopieren
mv -f $PKG$SOURCEDIR/include $PKG/usr # Normalerweise manuell und nur sobald glibc übersetzt wird !!!!!
echo "ls $PKG/usr/include : "
ls $PKG/usr/include
#rm $PKG$SOURCEDIR/include
ln -sf /usr/include $PKG$SOURCEDIR/include
fi
rdev -R $PKG/boot/vmlinuz* 0
rdev -v $PKG/boot/vmlinuz* 0
rdev -r $PKG/boot/vmlinuz* 0
rdev -R $PKG/boot/initrd.gz* 0
rdev -v $PKG/boot/initrd.gz* 0
rdev -r $PKG/boot/initrd.gz* 0
fi
#### Kernel fertig kopiert.
echo "6 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
ls $PKG$SRCSDIR >> $TMP/test.test
ls $PKG/boot >> $TMP/test.test
### ========== d) strippen : Nur für Programme: ( Den Kernel nicht strippen, auch sonst nichts im Kernel-Paket)
if test $KERNEL = 0 ; then
strip $PKG/bin/*
strip $PKG/sbin/*
strip --strip-unneeded $PKG/lib/*.so
strip $PKG/usr/bin/*
strip $PKG/usr/sbin/*
strip --strip-unneeded $PKG/usr/lib/*.so
strip $PKG/usr/local/bin/*
strip $PKG/usr/local/sbin/*
strip --strip-unneeded $PKG/usr/local/lib/*.so
#strip --strip-unneeded $PKG/usr/lib/$NAME/plugins/1.0.0/*.so # %%%
#strip --strip-unneeded $PKG/usr/lib/$NAME/plugins/1.0.0/post/*.so # %%%
#strip --strip-unneeded $PKG/usr/lib/$NAME/plugins/1.0.0/vidix/*.so # %%%
fi
### ================== e) Dokumente: entweder nach /usr/doc/$NAME (normal)
mv -f $PKG/usr/local/doc $PKG/usr/ # nach Standard-Platz kopieren
mv -f $PKG/usr/share/doc $PKG/usr/ # nach Standard-Platz kopieren
mv -f $PKG/usr/local/share/doc $PKG/usr/ # nach Standard-Platz kopieren
echo "7 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
ls $PKG$SRCSDIR >> $TMP/test.test
ls $PKG/boot >> $TMP/test.test
### Einige Anleitungen ref. Paket/Installierung in /usr/doc/$NAMETGZ
DOCDIR=$PKG/usr/doc/$NAMETGZ
mkdir -p $DOCDIR
mv -f $PKG/usr/doc/$NAME/* $DOCDIR # falsch
echo "Dokumente nach: " $DOCDIR
cd $SOURCEDIR
cp -aR \
AUTHORS *BUGS conf*.sh COPYING* CREDITS ChangeLog FAQ *HOWTO INSTALL NEWS README TODO dist \
$DOCDIR
cp -aR $KOPIEREN $DOCDIR # einfachs Kopieren, falls $KOPIEREN vorgegeben mit / , absolut, sonst rel. zu $SOURCEDIR
gzip $PKG/usr/man/man1/* # man-pages zippen
### ================== f) SlackBuild und Text-File .txt kopieren
mkdir -p $PKG/install
# default falls nichts besseres vorhanden:
cat << EOF > $PKG/install/slack-desc
$NAME: $NAMETGZ
$NAME:
$NAME:
$NAME:
$NAME:
$NAME:
$NAME:
$NAME:
$NAME:
$NAME:
$NAME: $DISTRONOTE
EOF
echo "8 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
ls $PKG$SRCSDIR >> $TMP/test.test
ls $PKG/boot >> $TMP/test.test
cp -f $PKG/install/slack-desc $TMP/slack-desc.ini
echo "Kandidaten für slack-desc in subdir TBZ2DIR,SOURCEDIR,PWDINIT:" $TBZ2DIR , $SOURCEDIR , $PWDINIT
echo " NAMETGZ, NAME* :" $NAMETGZ " , " $NAME*
ls -l $TBZ2DIR/$NAMETGZ.txt
ls -l $TBZ2DIR/$NAME*.slack-desc
ls -l $SOURCEDIR/$NAME*.slack-desc
ls -l $PWDINIT/$NAME*.slack-desc
echo "Versuch kopieren:" $TBZ2DIR/$NAMETGZ.txt $PKG/install/slack-desc # niederste Priorität: altes .txt auf Sammel-Dir aller Progs
cp -f $TBZ2DIR/$NAMETGZ.txt $PKG/install/slack-desc # niederste Priorität: altes .txt auf Sammel-Dir aller Progs
echo "Versuch kopieren:" $TBZ2DIR/$NV*.slack-desc $PKG/install/slack-desc # höhere Priorität: ggf. upgedatetes File
cp -f $TBZ2DIR/$NV.slack-desc $PKG/install/slack-desc # höhere Priorität: ggf. upgedatetes File
cp -f $TBZ2DIR/$NV$ZUSATZ.slack-desc $PKG/install/slack-desc # höhere Priorität: ggf. upgedatetes File
echo "Versuch kopieren:" $SOURCEDIR/$NV*.slack-desc $PKG/install/slack-desc # höhere Priorität: ggf. upgedatetes File
cp -f $SOURCEDIR/$NV.slack-desc $PKG/install/slack-desc # höhere Priorität: ggf. upgedatetes File
cp -f $SOURCEDIR/$NV$ZUSATZ.slack-desc $PKG/install/slack-desc # höhere Priorität: ggf. upgedatetes File
echo "Versuch kopieren:" $PWDINIT/$NV*.slack-desc $PKG/install/slack-desc # höchste was im Ordner ist von wo gestartet wurde
cp -f $PWDINIT/$NV.slack-desc $PKG/install/slack-desc # höchste was im Ordner ist von wo gestartet wurde
cp -f $PWDINIT/$NV$ZUSATZ.slack-desc $PKG/install/slack-desc # höchste was im Ordner ist von wo gestartet wurde
cp -f $PWDINIT/$NAME*$DISTRO.txt $PKG/install/slack-desc # höchste was im Ordner ist von wo gestartet wurde
if cmp $PKG/install/slack-desc $TMP/slack-desc.ini ; then
echo " ****> Beschreibung vom Programm ausfüllen !!!" # für neue Pakete; für alte vhd. slack-desc schon vorher ändern !
sleep 5
mcedit $PKG/install/slack-desc
fi
echo "definitives zurück kopieren:" $PKG/install/slack-desc $TBZ2DIR/$NV$ZUSATZ.slack-desc.new # " nach /downloads/Programs/prog-1.0-i486-1mn
cp -f $PKG/install/slack-desc $TBZ2DIR/$NV$ZUSATZ.slack-desc.new # " nach /downloads/Programs/prog-1.0-i486-1mn
echo "9 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
ls $PKG$SRCSDIR >> $TMP/test.test
ls $PKG/boot >> $TMP/test.test
echo "Versuch kopieren:" $TBZ2DIR/$NV*.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild # letztes *.SlackBuild --> /usr/doc/...
cp -f $TBZ2DIR/$NV.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild # letztes *.SlackBuild --> /usr/doc/...
cp -f $TBZ2DIR/$NV$ZUSATZ.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild # letztes *.SlackBuild --> /usr/doc/...
echo "Versuch kopieren:" $SOURCEDIR/$NV*.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild # letztes *.SlackBuild --> /usr/doc/...
cp -f $SOURCEDIR/$NV.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild # letztes *.SlackBuild --> /usr/doc/...
cp -f $SOURCEDIR/$NV$ZUSATZ.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild # letztes *.SlackBuild --> /usr/doc/...
echo "Versuch kopieren:" $PWDINIT/$NV*.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild # falls gepatchtes Skript läuft, halt .sonstwas nennen
cp -f $PWDINIT/$NV.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild # falls gepatchtes Skript läuft, halt .sonstwas nennen
cp -f $PWDINIT/$NV$ZUSATZ.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild # falls gepatchtes Skript läuft, halt .sonstwas nennen
echo "Versuch kopieren:" $SOURCEDIR/*.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild
cp -f $SOURCEDIR/*.SlackBuild $DOCDIR/$NAMETGZ.SlackBuild # höchste Priorität: $SOURCEDIR/*.SlackBuild
echo "definitives zurückkopieren:" $DOCDIR/$NAMETGZ.SlackBuild $TBZ2DIR/$NV$ZUSATZ.SlackBuild.new
cp -f $DOCDIR/$NAMETGZ.SlackBuild $TBZ2DIR/$NV$ZUSATZ.SlackBuild.new
echo "10 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
ls $PKG$SRCSDIR >> $TMP/test.test
ls $PKG/boot >> $TMP/test.test
echo "Install-Shell kopieren:" $TMP/doinst.sh $PKG/install/doinst.sh
cp -f $TMP/doinst.sh $PKG/install/doinst.sh # Install-Anweisungen kopieren
### ================= Attribute setzen
#if test $KERNEL != 0 ; then
chmod -R 755 $PKG/etc/rc.d/ # rc.modules.new
#fi
if test $KERNEL = 0 ; then
#chown -R root.root $PKG/usr/doc
#chmod -R 644 $PKG/usr/doc/$NV/*
#chown -R root.root $PKG/usr/include
#chown -R root.root $PKG/usr/man
#chown -R root.root $PKG/usr/share
chown -R root.root $PKG
chown -R root.bin $PKG/bin # verschiedene Prioritäten setzen
chown -R root.bin $PKG/usr/bin # verschiedene Prioritäten setzen
chown -R root.bin $PKG/usr/local/bin # verschiedene Prioritäten setzen
fi
echo "11 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
ls $PKG$SRCSDIR >> $TMP/test.test
ls $PKG/boot >> $TMP/test.test
### ==================== leere Ordner im Paketbaum löschen (nur soweit explizit angelegt)
rmdir $DOCDIR $PKG/etc/rc.d $PKG/etc $PKG/usr/bin $PKG/usr/sbin $PKG/usr/man/man5 $PKG/usr/man/man8 $PKG/usr/man $PKG/usr
### ==================== Paket aus Paket-Struktur ./pkg bilden
echo "*** Paket bilden: " $NAMETGZ.tgz " , md5sum: dgl. .md5 , Text: " $NAMETGZ.txt " alles nach: " $TBZ2DIR
cd $PKG
if test $KERNEL = 0 ; then
requiredbuilder -v -y $PKG # -s $CWD einfügen
fi
makepkg -l y -c n $TGZ > /dev/zero # makepkg ... /downloads/Programs/prog-1.0-i486-1mn.tgz
cd $TBZ2DIR
md5sum $TGZ > $TGZ.md5
cp -f $PKG/install/slack-desc $TBZ2DIR/$NAMETGZ.txt
### ==================== aufräumen , je nach $KEEPSRC
cd $SOURCEDIR
make uninstall # stets !
#if [ "$1" = "--cleanup" ]; then ... ; fi ; # Falls mit --cleanup aufgerufen, säubern
if test $KEEPSRC = 0 ; then echo " Uebersetzung / Quellcode löschen " ; rm -rf $SOURCEDIR ; fi ; # Normalfall
if test $KEEPSRC = 1 ; then echo " aufraeumen: make clean " ; cd $SOURCEDIR ; make clean ; fi ;
echo "12 TMP: " $TMP >> $TMP/test.test
ls $TMP >> $TMP/test.test
ls $PKG$SRCSDIR >> $TMP/test.test
ls $PKG/boot >> $TMP/test.test
### ===================== Paket ggf. installieren je nach $IFINSTALL Kernel NIE updaten !!!!
cd $TBZ2DIR
echo " KERNEL, IFINSTALL: " $KERNEL " " $IFINSTALL
if test $KERNEL != 0 ; then IFINSTALL=1 ; fi ;
echo " KERNEL, IFINSTALL: " $KERNEL " " $IFINSTALL
if test $IFINSTALL = 1 ; then echo " Paket installieren " ; installpkg $TGZ ; fi ;
if test $IFINSTALL = 2 ; then echo " Paket updaten " ; upgradepkg --install-new --reinstall $TGZ ; fi ; # Normalfall
cp $NAMETGZ.tgz $PUB # zum downloaden von $PUB freigeben
cp $NAMETGZ.tgz.md5 $PUB
cp $NAMETGZ.txt $PUB
#rm -rf $PKG # besser jeweils VOR Paketbildung löschen, bei Fehlern anguckbar
rm -r $TMP # später ggf. löschen lassen # wenn wir hier ankommen, schon alles im Paket
Zuletzt bearbeitet:
Ähnliche Themen
Audacity 3.0.0: Audioeditor erhält ein neues Projekt-Format [Notiz]
Audacity 3.0.0: Audioeditor erhält ein neues Projekt-Format [Notiz]: Der Open Source-Audioeditor und -Recorder Audacity erhält mit Version 3.0.0 sein erstes großes Update seit langem und mit .aup3 ein neues Projekt-Format...
es kommen abwechselnd neuere Distributionen...
es kommen abwechselnd neuere Distributionen...: es kommen abwechselnd neuere Distributionen, so dass ich fast immer nach einer gewissen Zeit die bisherige aktuellere Distribution anfange, weniger...
Update auf Apache >=2.4.12 unter Debian Jessie
Update auf Apache >=2.4.12 unter Debian Jessie: Hi,
aufgrund eines Bugs in Apache 2.4 benötige ich zum Deployment von Seafile unter Debian Jessie das Paket apache2 in der Version >= 2.4.12 (siehe Manual...
Firewall pfSense 2.3 erschienen
Firewall pfSense 2.3 erschienen: Version 2.3 der auf FreeBSD beruhenden Firewall-Distribution pfSense bringt unter anderem eine noch einmal neu geschriebene Weboberfläche und eine...
Slackware 14.2 als Veröffentlichungskandidat
Slackware 14.2 als Veröffentlichungskandidat: Patrick Volkerding hat bekanntgegeben, dass Slackware 14.2 jetzt als erster Veröffentlichungskandidat bereitsteht. Damit ist mit einer baldigen...
