Selbstkompilierte Software Yast bekannt geben

[MrMind]

Moin,

wenn ich über YOU nach Updates gucke und die Software mit der aktuellen Version von den Herstellern vergleiche liegen zumal die Updates auf dem FTP-Server immer weiter hinter her als es neuere Versionen gibt.

Da ich ja wegen Sicherheitslücken etc. die Programme updaten möchte lad ich sie mir dann manuell runter und kompiliere sie mir dann gleich. Wie kann ich nun aber Yast sagen, das ich eine neuere Version installiert habe als er sie kennt???

Das Problem ist einfach das, wenn ich zum Beispiel den Webserver installiert habe über Yast und ich will PHP updaten und tu dies selbst kompilieren, dann nimmt der Apache 2 die veränderung net war und nutzt die ältere Version von PHP. Deinstalliere ich PHP davor erst über Yast fallen einige nützliche Programme wegen der Abhängigkeit weg oder es lässt sich erst gar net deinstallieren.

Ich hoffe ihr versteht was ich meine.

Das sollte eigentlich alle SuSE Versionen betreffen, aber wenn ihr meine wissen wollt: 9.1

Mfg
MrMind

[traffic]

Moin,

wenn ich über YOU nach Updates gucke und die Software mit der aktuellen Version von den Herstellern vergleiche liegen zumal die Updates auf dem FTP-Server immer weiter hinter her als es neuere Versionen gibt.

Da ich ja wegen Sicherheitslücken etc. die Programme updaten möchte lad ich sie mir dann manuell runter und kompiliere sie mir dann gleich. Wie kann ich nun aber Yast sagen, das ich eine neuere Version installiert habe als er sie kennt???

Sorry, entweder Du hast etwas missverstanden oder Du liest grundsätzlich keine README-Dateien.

Von SuSE bekommst Du grundsätzlich niemals neue Versionen, und das ist auch gut so, weil diese Vorgehensweise das System konsistent hält. Das ist ja gerade der Vorzug von SuSE gegenüber anderen Distributionen.

Wenn bei SuSE die Software abc in der Version 1.2.3 mitgeliefert wurde und in genau dieser Version 1.2.3 eine Sicherheitslücke auftaucht, dann wird der Entwickler von abc wahrscheinlich einen Sicherheitspatch in die Nachfolgerversion 1.3.0 einbauen.

SuSE wird diesen Sicherheitspatch aus der Version 1.3.0 herauslösen, in die Version 1.2.3 einpflanzen, das Ganze abc 1.2.3-1 nennen und Dir dann diese Version 1.2.3-1 per YaST Online Update anbieten. In dieser Form bekommst Du den Sicherheitspatch. Und wenn es irgendwann eine zweite Sicherheitslücke geben sollte und der Autor von abc schon längst bei der Version 1.4.0 angekommen ist, dann wird SuSE die ganze Prozedur wiederholen und Dir am Ende in derselben Art und Weise wie vorher eine Version 1.2.3-2 von abc anbieten.

Wenn Du jetzt anfängst, selbst Hand anzulegen, dann stehst Du am Ende nicht sicherer, sondern sogar noch unsicherer da. Für die selbstkompilierten Programme bekommst Du nämlich überhaupt keine Updates, verspielst den Anspruch auf Support von SuSE und hast zusätzlich auch noch mehr Arbeit.

Lass Dich nicht durch die Versionsnummern täuschen, die Sicherheitspatches sind auf die alten Versionen zurückportiert und in den per YaST angebotenen Updates schon längst enthalten.

Das Problem ist einfach das, wenn ich zum Beispiel den Webserver installiert habe über Yast und ich will PHP updaten und tu dies selbst kompilieren, dann nimmt der Apache 2 die veränderung net war und nutzt die ältere Version von PHP. Deinstalliere ich PHP davor erst über Yast fallen einige nützliche Programme wegen der Abhängigkeit weg oder es lässt sich erst gar net deinstallieren.

Verstehst Du jetzt, weshalb Du die Updates von SuSE nehmen sollst? Genau deswegen macht das Vorgehen von SuSE Sinn, weil ein Patch dadurch die geringstmöglichen Auswirkungen auf die anderen Pakete hat und das System insgesamt konsistent hält. Diesen Vorteil verspielst Du durch das Selbstkompilieren komplett. Deshalb soll man bei den Paketen des Distributors bleiben.

Falls Du trotzdem unbedingt immer die neueste Version haben möchtest, hast Du zwei Möglichkeiten:

- Lerne, wie man RPMs baut. Das ist gar nicht so schwer. Links zu Tutorials kann ich Dir leider nicht nennen, weil ich es selbst nicht über Tutorials, sondern durch das Anschauen von Source-RPMs gelernt habe und somit keine Lust habe, extra nach Tutorials zu suchen. Sorry. Google weiß mehr.

- Verwende checkinstall. Das ist bei SuSE dabei, muss aber nachinstalliert werden. Anschließend rufst Du beim Kompilieren einfach "/usr/sbin/checkinstall" statt "make install" auf und beantwortest die Fragen, am Ende kommt ein RPM heraus. Allerdings wird die Nutzung vom checkinstall oft zu Recht als "quick and dirty" bezeichnet, aber es geht.

Aber denke daran, dass Du durch die Nicht-Nutzung von YaST Online Update und durch das Selbstkompilieren hauptsächlich zusätzliche Arbeit hast und außerdem sofort sämtliche Ansprüche auf Updates und Support von SuSE verlierst!

PS: Gerade sehe ich, dass Du die neuen Versionen auch noch über die von SuSE mitgelieferten drüberinstalliert hast. Na dann viel Spaß beim Aufräumen, das kann ja nur schiefgehen, YaST denkt jetzt nämlich, dass gar nichts aktualisiert worden sei und klatscht die Patches für die alten Versionen über Deine selbstkompilierten drüber, klasse. Da blickt dann ja irgendwann überhaupt niemand mehr durch. Die Moral von der Geschicht lautet, dass man YaST Online Update und die SuSE-Patches benutzen soll.

Wenn schon selbstkompilieren, dann bitte auch ein RPM draus machen. In dem Fall erkennt YaST nämlich an der fehlenden Digitalen Signatur, dass das selbstkompilierte Paket nicht von SuSE stammt und lässt es bei Onlineupdates in Ruhe.

Falls Du mit der Politik, dass es keine neuen Versionen, sondern nur zurückportierte Sicherheitspatches gibt und Du in Wirklichkeit nicht nur die Sicherheitspatches, sondern gleich komplett neue Versionen haben willst, dann bist Du bei SuSE eindeutig an der falschen Adresse. Es gibt Distributionen mit anderen Vorgehensweisen, manche liefern auch gleich neue Versionen. Falls Du das tatsächlich bevorzugen solltest, dann könntest Du über einen Wechsel der Distribution nachdenken.

[MrMind]

Jo danke für dein Umfangreiches Aufklären. Es hat mich etwas weiter gebracht @Versionsnummern.

Das SuSE dadurch konsitenz läuft wenn man so vorgeht ist gewiss, aber grad bei PHP ist das Problem, wenn ich es über Yast installiere habe ich net die Module, die ich brauche (bestes Beispiel: Sockets). Und seit dem ich mich da Wochen lang rumgeärgert habe und es letztlich irgendwie gepackt hatte, war das mit den Abhängigkeiten noch da gewesen. Deswegen hatte ich mich darüber auch sehr aufgeregt. Grad einen Webserver wenn dieser laufen soll und man kann PHP net so kompilieren wie man es gerne hätte ohne größere Umstände hat mich sehr ärgerlich gemeint.

Zu dem konsistenz kann man am besten Debian noch vergleichen und zwar die Woody Variante. Läuft immer noch mit Kernel 2.2 weil es am stabilsten ist

Naja RPM's selber bauen werde ich mir mal zugemüte legen, danke für den Tipp

zu checkinstall möchte ich nur sagen: Wenn ich was mach, will ich es richtig machen und net einfach was machen hauptsache es geht

Danke für deinen schnellen und sehr umfangreichen Beitrag.

Mfg
MrMind

[traffic]

Naja RPM's selber bauen werde ich mir mal zugemüte legen, danke für den Tipp

zu checkinstall möchte ich nur sagen: Wenn ich was mach, will ich es richtig machen und net einfach was machen hauptsache es geht

Aufpassen, so schlecht ist checkinstall nicht. Es macht nichts anderes als "make install", schreibt aber das Ergebnis zusätzlich noch in die RPM-Datenbank, womit das YaST-Problem gelöst wäre. checkinstall ist eine vernünftige und zeitsparende Option, wenn "make install" die Alternative wäre, weil es dasselbe macht, aber alles sauber aufzeichnet. Ich wollte checkinstall hier in keiner Weise schlecht machen.

Anders formuliert: Wenn Dir mal wieder nach selbstkompilieren, aber nicht nach RPM-Bauen ist, dann verwende checkinstall, weil das Ergebnis genau gleich ist, aber ganz nebenbei auch YaST davon erfährt.

Viel Erfolg

[MrMind]

Aufpassen, so schlecht ist checkinstall nicht. Es macht nichts anderes als "make install", schreibt aber das Ergebnis zusätzlich noch in die RPM-Datenbank, womit das YaST-Problem gelöst wäre. checkinstall ist eine vernünftige und zeitsparende Option, wenn "make install" die Alternative wäre, weil es dasselbe macht, aber alles sauber aufzeichnet. Ich wollte checkinstall hier in keiner Weise schlecht machen.

Anders formuliert: Wenn Dir mal wieder nach selbstkompilieren, aber nicht nach RPM-Bauen ist, dann verwende checkinstall, weil das Ergebnis genau gleich ist, aber ganz nebenbei auch YaST davon erfährt.

Viel Erfolg

Jo alles klar. Diesem Ratschlag komme ich gerne nach

Ich weiß das Selbstkompilieren mehr arbeit ist, aber mir ist immer lieber, wenn ich das alles selber mache, dann weiß ich wo die Sourcen liegen und wenn ich beim ./configure was vergessen habe einen Parameter zu übergeben den ich noch gebraucht habe, kann ich dies schnell nachholen

Ok, dann wende ich mich mal checkinstall zu und such mal nach RPM's bastel Anleitungen

Danke dir nochmals.

Hat mich gefreut, das man mir so schnell weiter geholfen hat

Mfg
MrMind

[frankpr]

Mit Deinen Anforderungen wärst Du eigentlich mit LFS oder einer Sourcedistribution besser bedient.

[MrMind]

Mit Deinen Anforderungen wärst Du eigentlich mit LFS oder einer Sourcedistribution besser bedient.

Ich hatte schon Ubuntu bei mir auf dem Rechner, aber das Problem war dann meine Fritz-ISDN-Karte, die hat Probleme gemacht, daher bin ich auch wieder auf SuSE zurück gegangen, da dies einwandfrei klappt.

Evtl. bin ich mir am überlegen ob ich net FC3 auf meinen Desktop-PC installieren sollte.

Mfg
MrMind

[frankpr]

Ich habe von Sourcedistributionen geschrieben, nicht von Binärdistributionen wie FC3 oder Ubuntu.
Bei denen bestimmst Du weitestgehend selbst, wie welches Programm gebaut wird, welche Features unterstützt werden, ....

[MrMind]

Ich habe von Sourcedistributionen geschrieben, nicht von Binärdistributionen wie FC3 oder Ubuntu.
Bei denen bestimmst Du weitestgehend selbst, wie welches Programm gebaut wird, welche Features unterstützt werden, ....

Aso, sorry damit habe ich mich noch net auseinander gesetzt.

Mfg
MrMind

[Painkiller]

Fedora ist schon OK