glib2-2.56.1-375.2.src: No package 'libpcre' found // Gimp2.10 unter Leap42.3

Hinweis: In dem Thema glib2-2.56.1-375.2.src: No package 'libpcre' found // Gimp2.10 unter Leap42.3 gibt es 73 Antworten auf 8 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • 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.

    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.

    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 <3 , 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

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    9 Mal editiert, zuletzt von TuxSv748 ()

    Für den Inhalt des Beitrages 122160 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • Tja, wieder so ein Ding.


    Das TLDP ist ziemlich generisch.
    Hat also mit openSUSE (oder jeder anderen Distri) nur am Rande zu tun.


    Würdest du dir mit LFS dein Linux selber bauen, wäre obige Dokumentation näher an deinem Verhau.
    (Aber selbst dort würde das wohl Ärger geben)


    Anders formuliert: Einen Bugatti Veyron kannst du getrost "Auto" nennen. Dann aber durch das Konzept "Auto" verbunden aus einem Ford Model T eine Konstruktionsanleitung für einen Veyron abzuleiten, funktioniert nicht so recht.

  • 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.

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Für den Inhalt des Beitrages 122162 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • openSUSE / SUSE betreibt den sogenannten OBS ( OpenBuildService ).
    Würde man sich dort einarbeiten, hätte man IMMER für diverse Distris lauffähige Pakete,
    ohne dass der User selbst großartig kompilieren müsste.


    Dein Gimp liegt dort längst fertig gebaut.
    Hättest du schlicht das dortige Gimp installiert, hättest du dein System nicht mit deinen eigenwilligen Kompilierungsversuchen zerhackt.
    (und in Folge davon, dann auch nicht Sauerlands Fähigkeit dort Pakete zu bauen bezweifeln müssen).
    Es würde schlicht längst laufen.


    Dein Gerede von allgemeingültigen Dokus ist ganz allgemein bei allen Distris unzutreffend.
    Wenn du heute nicht die jeweiligen Gegebenheiten der verschiedenen Distris berücksichtigst,
    kriegst du allenfalls sehr schlichte Programme kompiliert. die dann überall laufen.


    Egal, ob dir das passt, oder nicht, ob du das einsiehst, oder nicht:
    Deine Denkhaltung ist längst ausgestorben, weil schlicht heute nicht mehr umsetzbar.
    Dazu ist die Linuxwelt mittlerweile viel zu komplex und viel zu sehr diversifiziert.
    Es gibt keine universellen Rezepte, Dokus oder Pakete.
    Heute ist dafür wesenziell mehr Hintergrundwissen nötig.
    Das ist übrigens mit ein Grund und Motivation den OBS zu betreiben.
    Dort kannst du deine Zoffware für Debian, Fedora und openSUSE gleichzeitig bauen.
    Und wenn dir das immer noch nicht genügt, kannst du die OBS Infrastruktur so modifizieren,
    dass auch für deine SteizeitDistri B52 sauber installierbare Pakete gebaut werden.
    Arch und Gentoo Pakete kannst du dort auch jetzt schon basteln.


    Man mag in einer sehr kleinen und spezifischen Domäne mit diesem Anspruch noch hantieren.
    Aber selbst darin wäre es eine reine contradictio eo ipse causa, da dieser Anspruch dann eben nur in dieser geschränkten Domäne gilt,
    was eben gerade nicht universell ist.

  • und noch eine finale Anmerkung:

    ... sachwissensfrei

    • openSuse ist ein rein privates Gelegenheitshobby
    • in meinen >20Jahren Berufsleben ist mir im professionellen Umfeld noch NIE Suse/openSuse zu Gehör gekommen oder über den Weg gelaufen / eingesetzt worden:
      (redhat) Ubuntu YOCTO etc. ...
      Von diesem Standpunkt aus ist openSuse ein Exot, und warum sich in Spezifika einarbeiten die evtl openSuse spezifisch sind, im allgemeinen (Berufs-)leben ohne Belang sind.
      Angenommen/Wenn Suse hier etwas eigenes macht entgegen der 'Regel' dann ist es proprietäre Software, auch wenn sie open source ist.
    • mache Betrachten Debian als die reine Lehre: aber jeder hat seinen eingenen Gott.


    in diesem Sinne zu "sachwissensfrei".


    "Würde man sich dort einarbeiten" .. (und weiterem)

    • vs .. würde man die Zeit haben. -> priv. Gelegenheitshobby

    "Dein Gimp liegt dort längst fertig gebaut."

    • mag ich über software.opensuse.org nicht gefunden haben - don't remember -
      wie geschrieben bevorzuge ich primär offizielle Pakete gegenüber home:Community Paketen, auch wenn die Release dadurch die höhere ist.

    "mit deinen eigenwilligen Kompilierungsversuchen zerhackt"

    • ich habe nie etwas davon installiert, da schon das Compilieren nicht durchgelaufen ist. Wo nix gebaut wird kann nix installiert werden :!:

    "Sauerlands Fähigkeit dort Pakete zu bauen bezweifeln müssen"

    • ich habe dies nie bezweifelt, nie derartiges geschrieben!, .. mich bedankt .., es hat nur letztendlich zum selben Fehler geführt der durch Installation/Update von libgconfig behoben war.

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    4 Mal editiert, zuletzt von TuxSv748 ()

    Für den Inhalt des Beitrages 122166 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • es hat nur letztendlich zum selben Fehler geführt der durch Installation/Update von libgconfig behoben war.

    Der Fehler war, das du vorher schon Leap 15.0 Pakete hineingeprügelt hast, und nicht in der Lage warst, dies zu bereinigen.
    Das von mir gebaute gimp läuft!

    Für den Inhalt des Beitrages 122167 haftet ausdrücklich der jeweilige Autor: Sauerland

  • müsste durch die Historie des Threads zurück um zu ermitteln um welches Paket es sich handelt.


    Vor der Installation deiner Pakete habe ich mit zypper rm bestmöglich die Vorversionen entfernt.
    Meines Wissens kam die Abhängigket nach libgconfig aus libgimpconfig, und dies ist Teil der von dir bereitgestellten Pakete. (nur dort existiert/-en g_object_new_with_properties)
    (wie auch immer: ich kann den Zustand nicht mehr reproduzieren und möchte es auch nicht. Ich hatte mich damals bedankt für die aktive Hilfe/Zuarbeit und kann dies auch nochmals tun <3 DANKE <3 )
    jetzt läuft gimp eben nach meiner Vorgehensweise.



    ps: aus etlichen Berufsjahren kenn ich die Aussage (von Kollegen - und auch mir) "Auf meinem Rechner läuft's" - diese ist (/war meist) keine verlässliche Information!

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    2 Mal editiert, zuletzt von TuxSv748 ()

    Für den Inhalt des Beitrages 122169 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • SUSE ist auf S340/390 Großrechnern schon immer der Platzhirsch gewesen, ist es und bleibt es.
    Und ich erspare es uns allen, aufzählen, wo SUSE noch ganz vorne mitspielt.
    Davon noch nie etwas gehört zu haben, lässt tief blicken.


    Dein berufliches Umfeld halte ich für ziemlich verengt.
    Und all deine Aussage bestätigen mir das.

  • ich bin nicht im Bankenwesen tätig, falls dies ein Einsatzgebiet ist.
    im Tele-(phon)-Kommunikationsbereich, Automobil, Aero/Luftfahrt, embedded etc ... ist *Suse kein Thema.


    * S340/390 Großrechnern == Sparte


    Es geht jetzt nicht um Grossrechner in Rechenzentren sondern um Server und Arbeitsplatzrechner die lokal in den Firmen laufen für Entwicklung (lokal/Jenkins), Projektierung, etc., auch da war Solaris oden HP/UX dominant, und um Programme/Produkte die für ein (embedded) Linux geschrieben werden.
    Entweder es wird unter MS/Visual Studio cross entwickelt oder auf Ubuntu. ... Und das Arbeits- und Zielsystem ist nie *Suse.


    andere(r) Arbeitgeber andere Philosophie - Spartensicht


    * ist hier ja kein Grossrechnerforum sondern openSuse/Linux, was auf jeder HW laufen soll


    was ist das Kriterium?
    wenn 100.000 Entw. bei BOSCH Software im Automobilbereich entwickeln und keinen Suse Kontakt haben ..vs.. 100 die für eine Bank Software für Suse-Großrechner schreiben.. -> verengtes berufliches Umfeld?
    ich kenn keine Herd/Kühlschrank mit Display auf dem Suse läuft. Es werden aber 1Mio davon verkauft im Vergleich zu 5 Großrechnern auf denen Suse läuft.


    Und all deine Aussage bestätigen mir das.

    ..ts...ts..ts

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    2 Mal editiert, zuletzt von TuxSv748 ()

    Für den Inhalt des Beitrages 122174 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • Deine an dünnstem Haar nachträglich hinzugezogenen sophistischen Ausflüchte zeigen zweierlei:
    Du hast wirklich keinen Überblick über das weite Linuxfeld.
    Und du würdest eher die Sonne zu einem Asteroiden umdefinieren,
    bevor du einmal vor deiner Türe kehrst.


    Übrigens zählen Kühlschrankdisplays von Automobilzulieferer nicht wirklich zu Linuxworkstations.
    (Außer vielleicht für studierte Software- Ingenieure.)


    Deine Argumentation ist ebenso wenig überzeugend, wie dein vogebliches Wissen über Linux.
    Und jetzt kannst du dich alleine langweilen.