Beiträge von TuxSv748

Zitat von Berichtigung

Das TLDP ist ziemlich generisch

Sie gehen zumindest noch auf FreeBSD ein.

Suse hat früher schon gerne ein eigenes Süppchen gekocht, abweichend von RedHat und anderen ... Ich weiß nicht ob Suse ein entsprechendes Dokument veröffentlicht hat bzw. von diesem Schema abweicht. Man kann nicht alles lesen und auf Differenzen prüfen. Die Beschreibung ist zumindest recht allgemein gehalten und dürfte auf viele Systeme zutreffen.

Wenn openSuse davon wiederum abweicht, was man sich so allgemein im Web ergooglen kann dann ist das ein anderes Problem.

Zitat von Berichtigung

Dir fehlt schon das Seepferdchen.

ob Seepferdchen, Bronze/Silber/Gold:
lieber mit Seepferdchen oder weniger das Ziel erreichen ( was ich in meinen Augen erreicht habe ) denn als Weltmeister ausscheiden.

Zitat von Berichtigung

redest du lieber die Leistungen anderer einfach schlecht.

ich hab mich für die Zuarbeit explizit bedankt. Ansonsten seh ich keine Leistungen die ich hier schlechtgeredet habe.

Zitat von Berichtigung

Deine Vorstellungen sind lächerlich und einem Menschen deines Berufes sollten sich dabei eigentlich alle Finger- und Zehennägel hochbiegen.
Deine Theorien sind durch die Bank verkehrt und ziemlich sachwissensfrei.

.. folgt ..

Für all die Gast-/Mitleser, und es gab reichlich Aufrufe , kurz einen Verweis auf ein offizielles Dokument, worauf sich mein Optimismus stützt auch mit diesem (nicht empfehlenswerten) Vorgehen keinen Schiffbruch zu erleiden: HOWTO/Program-Library-HOWTO/

• 3.5. Installing and Using a Shared Library
  ...
  Usually you can update libraries without concern; if there was an APIchange, the library creator is supposed to change the soname.That way, multiple libraries can be on a single system, and the rightone is selected for each program
• 3.6. Incompatible Libraries
  ...
  Fortunately, on Unix-like systems (including Linux) you can have multiple versions of a library loaded at the same time, ...

Ergänzend:

• Wenn ein Programm/Paket (rpm) ... Files installiert und diese im programmeigenen Unterverzeichnis ablegt dürfte dies keines der anderen installierten Programme tangieren
• Dateien die in gemeinsammen Verzeichnissen liegen dürften problematischer sein, Überschneidungen sollten aber nicht häufig vorkommen. Dasselbe File in 2 unterschiedlichen Paketen vorzufinden eher ausgeschlossen sein.
• shared-libraries -> siehe HOWTO

und

• prinzipiell würde ich Pakete aus den offiziellen Repos auch neuere Releases als besser getestet betrachten im Vergleich zu Angeboten aus home:Community, weswegen ich dies bevorzugen würde. (nur meine priv. Einschätzung)

Bzgl meines Startbeitrags #1 muss ich ergänzen, dass ich die Fehlermeldung von gimp für falsch oder zumindest irreführend halte. Es ist nicht glib2 die Probleme verursacht, sondern, siehe Beitrag #55, libgobject-2, und diese lässt sich unabhängig, einzeln updaten.

Beitrag #55 habe ich hinzugefügt, um letztendlich den 'Erfolg' zu belegen um den Thread als gelöst betrachten zu können. Der ganze zusätzliche Aufwand glib2 nachzubauen wäre nicht in Betracht gekommen, wenn die Fehlermeldung anders gelautet hätte.

".. deines Berufes...":
ich bin hauptsächlich erst mal alles andere, ... und zuletzt evtl noch Administrator, der sich mit Updates etc beschäftigen muss

ich denke so langsam dreht es sich etwas im Kreis

Zitat von Sauerland

Auch die funktionieren nur einwandfrei mit der und für die Version, für die sie gebaut wurden

natürlich, und die Anhängigkeiten lass ich durch yast automatisch auflösen. Wenn yast für das Update entsprechende Pakete als notwendig auflistet wird das mit installiert. Wenn Gimp aus Leap15 ist dann holt er sich die Abhängigkeiten eben auch aus Leap15. Und unterschiedliche libs mit unterschiedlichen Versionen können unter z.B. /usr/lib64/ koexistieren, entweder physikalisch, oder als link auf eine andere. Seh ich kein Problem (mag wieder zu Kommentaren führen)

Zitat von Berichtigung

Du hörst auf keinen guten Rat

(welcher Rat) weitestgehend der Hinweis es so nicht zu machen, dem hab ich ja zugestimmt (nicht widersprochen). Mit dem Hinweis auf meine Erfahrungen, dass dies BEI MIR in der Vergangenheit NOCH NIE zu Problemen/Instabilitäten geführt hat. Ich will dies ja auch nicht als Empfehlung an andere weitergeben !!!. Wollte nur letztendlich zeigen, dass es auch diesmal SO wieder geklappt hat gimp2.10.2 ans Laufen zu bekommen.

Zitat von Berichtigung

Lasse deine wilden Installationsorgien, fasse keinen Compiler mehr an.

Für diese Installationsorgien war kein Compiler notwendig. Rein auf Basis existierender Pakete auf Repos von openSuse-Leap15 (graphics und OSS). (siehe #55)

Der Titel des Thread basiert darauf, eine einzelne lib bauen zu wollen, weil ich ... müsste nachschauen was ich oben geschrieben habe. (auf Basis existierender Pakete, siehe #55, ist kein Compilereinsatz notwendig)

"beschränke dich auf die Standardrepos":

• openSuse-Leap15 (graphics und OSS).
  

  
  

"Mit dem Compiler sollte man nur in den Installation herummarodieren ...":

• prinzipiell nie in Zusammenhang mit openSuse, ausser für VirtualBox-Module auf Linux-Host, die man nachbauen muss nach kernel-updates
  

  
  

Ich kompiliere vorzugsweise nur meinen eingenen Sourcecode. (und verwende manchmal fertig kompilierte Pakete aus höherwertigen Releases)

.. so, .. zur Nacht ...

Zitat von Sauerland

Dein Vorgehen ist einfach nicht zu empfehlen

Da will ich nicht widersprechen.

abschließend doch noch ein paar Bemerkungen meinerseits

• in diesem Fall / gimp wären Sourcen vorhanden. Aber wie verfahre ich wenn ich keine Sourcen habe 'closed source (?)' oder fertiges binary/rpm?
  wegen 1l Milch die ganze Kuh kaufen? sprich Komplettupgrade?
• und: in meinem Fall läuft es momentan unter VirtualBox.
  Wenn ich ein Upgrade von Leap42 -> Leap15 o.ä. durchführen würde, könnte es bedeuten, dass ich dafür evtl VirtualBox auch Upgraden muss.
  Andererseits habe ich die Erfahrung mit einem Upgrade von VirtualBox gemacht, dass eine ältere openSuse Installation danach nicht mehr standardmäßig/vollständig supported wurde, sprich die GuestAdditions scheinen nicht mehr komplett zu funktionieren, konkret vboxsf. Damit kann ich die vom Host bereitgestellten Folder/Verzeichnisse nicht mehr direkt einbinden.
  + Evtl lässt sich dies wieder durch im Internet aufzufindende GuestAdditions beheben.
  + Benötige ich dann die pae oder die default Version? (ein uname -a sagt default) etc. Es tun sich hiermit nur neue Probleme auf, die bei meinem partiellen Teilupgrade nicht vorhanden sind.
• . . . nicht zuletzt/unerheblich: hat seither so funktioniert und wird hoffentlich weiterhin so funktionieren.
  UND: Ich setz damit auf offizielle openSuse Pakete auf. Muss nicht/weniger befürchten, dass von irgendwo bereitgestellte Pakete etwas einschleppen - Viren, Bitcoin-Miner, Backdoors - etc

Zitat von Sauerland

mit dem Paketbau beschäftigen

das kostet zumindest Zeit ...

Grüße, ... auf weiteres ...

Zitat von TuxSv748

früher gab es auch noch console mit 'c', evtl immer noch - ist wohl aber eher belanglos

kurz zur Aufklärung, Erläuterung meines Standpunkts.

ich habe den Betriff console hier nur erwähnt da er sprachlich mir Konsole verwechselt werden könnte.
Dass eine console kein xterm bzw. Ersatz ist, ist mit bewusst.

'evtl immer noch':
bezieht sich darauf, dass es mir zuletzt nicht mehr so häufig 'über den Weg gelaufen ist'. Ich kann mich an Zeiten erinnern, als auf jedem Unix Windows System HP-UX, Solaris, evtl Linux, openSuse etc. es so eingerichtet war, dass grundsätzlich eine console mit dem login geöffnet wurde.
Diese Vorgehen ist mir in den letzten Jahren nicht mehr aufgefallen: Die Notwendigkeit eine console unter X-Windows geöffnet zu haben scheint nachgelassen zu haben -> daher: '.. ist wohl aber eher belanglos'

Grüße

Zitat von Sauerland

Richtig wäre:

... aber vielleicht nicht notwendig.

* geht nichts - gibts nicht
( und: einem Ingeniör ist nix zu schwör - oder wie lautet der Spruch )
* was nicht passt wird passend gemacht!

Ich hatte mich letztendlich wieder entschlossen mein altes Vorgehen wieder aufzunehmen und die Pakete aus dem Grafik Repo von Leap 15 herunterzuladen, und (einzeln) zu installieren.

abgesehen von den src.rpm Files die ich testweise ausgepackt, letztendlich aber nicht gebaut und installiert habe sind dies die Pakete die ich nun installiert habe.

libgobject stellt schließlich die lib bereit die das zuvor nicht aufgefundene symbol g_object_new_with_properties beinhaltet.
Da beim Installationsversuch via yast2 auch dort Anhängigkeiten auftraten die nicht automatisch aufgelöst werden konnten habe ich mich hier entschlossen kurz/temp. das entsprechende Leap15-OSS hinzuzufügen.
sudo zypper ar http://download.opensuse.org/distribution/leap/15.0/repo/oss/ Leap15.0-OSS
letztendlich gab es nur eine weitere Abhängigkeit zu libffi.

Nachdem nun alles installiert war: der Aufruf von gimp ->

und

Funktioniert.

Ich habe somit ein aktuelles Leap42.3 mit gimp aus Leap15 und Abhängigkeiten teilweise upgegraded.

Meiner Meinung nach sollte dies generell möglich sein - ohne Probleme. Wenn ein System abwärtskompatibel ist, d.h. in Leap15 Programme aus Vorversionen installiert werden können, dann muss es auch aufwärtkompatibel sein. Der einzigste Knackpunkt der mir hier einfällt sind die neueren libs die notwendig sind. Diese sind versioniert und können parallel existieren.

Ansonsten: Liebe Kinder, nicht nachmachen .. ( und sie werden es erst recht tun. )
Vielen Dank für die zahlreichen Beiträge,Ratschläge und aktive Zuarbeit, ... man kann viel lernen.

Grüße,

Evtl gibt es bei openSuse ja etwas in dieser Richtung, aufgefallen ist es mir momentan noch nicht.

Vielleicht wäre es sinnvoll bei der Installation Schemas anzubieten ( nicht nur: HD booten / Installation / Memorytest .. )

• Home ... ( bevorzugtes Filesystem ext4, & entsprechende Programmauswahl zur Installation, z.B. ohne Entwickler Paket (gcc/g++) )
• Professional ... ( bevorzugtes Filesystem 'xy', professionellere Paketauswahl als default Vorschlag )
• Enterprise ... ( Profieinstellungen: btrfs + xfs, Entw. Pakete gcc/g++ linux-sourcen, .... )
• . . .

wie eine Firma aus Seattle mit M+$. Jeweils eine andere default-Paketauswahl bzw. auch anderes Partitionierungsvorgehen, was sich aber ändern/modifizieren lässt im Installationsverlauf.

( würde mich dennoch wohl für Enterprise entscheiden und ext4 wählen )

Zitat von Berichtigung

Dann ist heutzutage die Schrift zu klein und die Mouse verhält sich anders.

eben - und auf dieses hatte ich meinen Vergleich bezogen.

xterm = xterm, ja, aber irgendwo muss ich auch unterscheiden.
wenn ich ein Programm mit  $:> xterm starte, dann ist es für mich xterm.
wenn ich es mit S:> Konsole starte dann ist es Konsole für mich, auch wenn es funktional einem xterm entspricht.
(sonst verwirrt es evtl. einen Anfänger, wenn man sagt starte ein xterm und der Befehl lautet Konsole)

früher gab es auch noch console mit 'c', evtl immer noch - ist wohl aber eher belanglos. ( und evtl kterm und cterm ... - nicht so meine Richtung )

will das Thema auch nicht endlos weitertreiben '.'

Zitat von TuxSv748

was ein xterm nicht bietet.

ich hab es hier explizit mit xterm verglichen, Konsole hat(te) bei mir bisher keine Bedeutung düfte aber dem Funktionsumfang/Komfort dem Terminalfenster im Dolphin entsprechen.
Da das xterm in der default Einstellung am Bildschirm bei gleicher Informationswiedergabe weniger Bildschirmfläche einnimmt, und auf anderen Unix systemen verfügbar ist, war das bisher mein Standard, neben dolphin mit aktiviertem Terminalfenster.

Zitat von Berichtigung

Es ist falsch zu glauben, dass man keine Mouse in der Konsole verwenden kann.
Das konnte man mit jedem Xterm schon immer, auch wenn man es früher®™ erst aktivieren musste.

wenn ich im xterm einen Bereich markiere (per Maus) und dann rechte-Maustaste betätige, so verändert sich der markierte Bereich, aber es erscheint kein Kontextmenu, das ist der Unterschied den ich gemeint hatte, zumindest bei meinen Einstellungen.

ich bevorzuge seit einiger Zeit diese Variante, auch weil man im Terminal Text per Maus markieren und über rechte-Maustaste-Kontextmenu dann in die Zwischenablage kopieren kann, was ein xterm nicht bietet.