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.
  • heute nicht mehr - demnächst.


    Bin schon öfters so vorgegangen, wenn eine aktuellere Release vorliegt und das gewünschte rpm/Paket nicht von meiner installierten Release bereitgestellt wird, dann hab ich eben die Version der neueren Release verwendet, per yast auf Konflikte und Abhängigkeiten prüfen lassen - so wie hier auch - und es hat immer funktioniert.


    Wenn neuere libs nötig waren, dann existieren die ja i.d.R parallel mit den alten.


    Das alles waren ja die offiziellen openSuse Pakete - nichts von home:Sauerland zu dem Zeitpunkt.

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

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

  • Das alles waren ja die offiziellen openSuse Pakete - nichts von home:Sauerland zu dem Zeitpunkt.

    Das hat doch damit nicht zu tun.
    Du merkst doch gerade selbst, das eine neuere Version zwar installiert werden kann, aber nicht unbedingt funktionieren muss.


    An alle Querleser:
    Bitte so etwas unterlassen, es wird über kurz oder lang nicht funktionieren.


    Und damit ist hier für mich Schluss.

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

  • dass eine neuere Version zwar installiert werden kann, aber nicht unbedingt funktionieren muss

    diesmal wohl nicht, all die anderen Male zuvor hat es funktioniert, sonst hätte ich es diesmal ja auch nicht wieder so gemacht .. (gibt immer ein 1.Mal)
    Wenn die Anhängigkeitsprüfung sauber aufgesetzt ist sehe weiterhin kein Problem darin. Ist ja LINUX und nicht WINDOWS


    Das hat doch damit nicht zu tun.

    Doch - damit müssten die angebotenen Pakete in sich stimmig gewesen sein.


    Will aber damit keine Anleitung für Einsteiger liefern - also so was lassen - Finger weg <X

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

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

  • Richtig wäre:
    das src.rpm herunterladen, aus welchem man ein Paket installieren möchte, dieses neu für seine Version bauen mit:

    Code
    rpmbuild--rebuild xxxsrc.rpm

    Wenn dann noch irgendwelche Pakete in höheren Versionen angemeckert werden, muss ich die halt vorher als src.rpm herunterladen und mit rpmbuild --rebuild bauen, bis ich das Pakete bauen kann, welches ich benutzen möchte.
    Ist halt so.


    Du hast einfach die rpms (nicht src.rpm) heruntergeladen und ins System geprügelt.
    Was da an Problemen entstanden ist bzw. entsteht, ist nicht abzusehen.
    Deswegen sollte man so etwas nie nie machen.


    Und wenn ich dann so deine Beiträge lese..........

    Für den Inhalt des Beitrages 122000 haftet ausdrücklich der jeweilige Autor: 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,

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

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

  • Dein Vorgehen ist einfach nicht zu empfehlen.


    Und damit ist Schluss.


    * geht nichts - gibts nicht
    ( und: einem Ingeniör ist nix zu schwör - oder wie lautet der Spruch )Ich würde mich mal mit dem Paketbau beschäftigen und keine krummen Sachen machen......

    Ich würde mich mal mit dem Paketbau beschäftigen und keine krummen Sachen machen.
    Denn irgendwann wirst du mit deiner Vorgehensweise Probleme bekommen......


    Übrigens gibt es gimp 2.10 incl aller Abhängigkeiten in meinem Repo, da brauch ich kein Leap 15.0 Repo......

    Für den Inhalt des Beitrages 122110 haftet ausdrücklich der jeweilige Autor: 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


    mit dem Paketbau beschäftigen

    das kostet zumindest Zeit ...


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

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

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

  • UND: Ich setz damit auf offizielle openSuse Pakete auf.

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

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

  • Es reicht.


    Du hörst auf keinen guten Rat.
    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.
    Statt einzusehen, dass du dir die Probleme selbst bereitest,
    redest du lieber die Leistungen anderer einfach schlecht.


    Ein guter Rat:
    Lasse deine wilden Installationsorgien, fasse keinen Compiler mehr an.
    Lerne stattdessen den Umgang mit openSUSE und beschränke dich auf die Standardrepos.


    Mit dem Compiler sollte man nur in den Installation herummarodieren,
    wenn man den großen Linuxrettungsschwimmerschein hat.
    Dir fehlt schon das Seepferdchen.

  • ich denke so langsam dreht es sich etwas im Kreis

    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)

    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.

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

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

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