Laptop, spezielle Repos, Priorisierung

Hinweis: In dem Thema Laptop, spezielle Repos, Priorisierung gibt es 36 Antworten auf 4 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.

    Grafikkartentreiber sind eigentlich nur in den speziellen Repos vorhanden und damit müssen diese eigentlich nicht priorisiert werden. Bei Bumblebee ist das mittlerweile anders, glaub ich zumindest, die Pakete gibt es auch im OSS???


    Auf gut Deutsch:
    Wenn ich ein Repo einbinde, in dem die einzige Version eines Paketes liegt, brauch ich eigentlich keine Prioritäten, ebenso brauch ich für ein Repo keine Prioritäten, wenn ich daraus alle Pakete per Hand installiert habe, obwohl es diese in einem anderen Repo noch gibt. zypper up macht keine Repowechsel..
    Achtung:
    Bei Tumbleweed muss man eigentlich immer statt zypper up ein zypper dup machen und damit ist natürlich eine vernünftige Priorisierung von Nöten........

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

    Gut, ich habe mal ausschließlich packman auf Prio=20 gesetzt. Alles andere Standard (99) Nun macht zypper up m. E. kein Update über alle Repos. Also wäre ein zypper dup mit vernünftiger Priorisierung zu bevorzugen. Wie bei Tumbleweed eben auch. Nun habe ich simuliert:


    Die Anbieteränderung einiger Pakete zum OBS wäre ja wohl okay? (Das mit dem Flashplayer kann ich lösen.) Aber wieso werden die 32-Bit-Pakete installiert? Wie kann man das verhindern? Damit müsste ja mit zypper dup ein vollständiges und korrektes Update über alle Repos möglich sein? Wie bei Tumbleweed zwingend notwendig.


    Das mit dem Franken-Debian habe ich mir nicht selbst ausgedacht: DontBreakDebian - Debian Wiki
    Passt doch genau zu meinem Problem, findet ihr nicht? Scxhönes WE und Dank für die Geduld.

    Für den Inhalt des Beitrages 95626 haftet ausdrücklich der jeweilige Autor: Jana

    • Ein zypper up macht alle nötigen Updates aller Repos. Man braucht im täglichen Leben niemals ein zypper dup
    • Ein zypper dup hat im täglichen Leben nichts verloren. Es kommt nur EINMAL zum Zuge, wenn man an den Repos gefummelt hat.
    • Wer sich nicht daran hält, wird ein Supportforum-ganz-viel-Threaderöffner, oder Profi.


    OBS ( OpensuseBuildService) ist letztlich eine Renderfarm, die das Packaging und das Kompilieren anbietet.
    Man kann dort Pakete für alle möglichen Distris bauen, auch Debian.
    Und natürlich werden dort AUCH alle Varianten von (open)SUSE gebaut.
    Wer von dort mal einfach so irgendwas einbindet, gehört zu Punkt 3 oben.


    Nimm das freshplayerplugin, und das Thema ist erledigt. Mehr braucht es nicht.


    Und nochmal: Die Begriffe update/upgrade haben bei Debian und (open)SUSE völlig unterschiedliche Bedeutung.
    Ein apt-get update && apt-get upgrade entspricht einem zpper up.
    Ein zypper dup entspricht einem vi /etc/apt/sources.list && apt-get update && apt-get upgrade


    Dass Tumbleweed, das ich nicht nutze, immer ein dup will, scheint mir aus träger Bequemlichkeit falsches zu vermitteln.
    Ja, einem dup wohnt natürlich ein implizites up inne.
    Mach es einfach nicht. Du hast 13.2 und kein Stumbleweed.

    @Sauerland: Habe ich gemacht, danach zypper dup --dry-run:

    Zitat

    Stell irgendwo in "Yast----Software------Software installieren und löschen" um auf "Ignoriere empfohlene Pakete für bereits installierte Pakete".

    Keine Auswirkungen, die 32-Bit-Pakete, sollen nach wie vor NEU(!!!) installiert werden. Deshalb wäre es unwahrscheinlich, wenn das geklappt hätte.





    Berichtigung:


    Wenn ich das hardware -Repo, aus dem die OBS-Pakete kommen, geringer priorisiere, z. B. 120, erfolgt mit zypper dup kein Anbieterwechsel. Allerdings will das System immer noch 32-Bit-Pakete installieren. Habe natürlich nur simuliert.
    Dein Vergleich war vermutlich nicht ganz exakt: Ein zypper dup sollte eher einem apt-get dist-upgrade entsprechen. Mit letzterem erfolgt genau dasselbe, wie bei apt-get upgrade, wenn ich nur die Quellen von Jessie eingetragen habe - und nicht testing oder stretch. Ein zypper dup führt auch einen Anbieterwechsel entsprechend Priorisierung durch, habe ich beim Testen bemerkt. Genau das war eigentlich mein Ziel: Ein exaktes Upgrade über alle Repos entsprechend Priorisierung. Da dürfen aber keine 32-Bit-Pakete neu installiert werden und ich weiß nicht, warum. Ist bis jetzt der einzige Unterschied zu apt-get dist-upgrade.


    Dann frage ich mich, warum es im Netz keine Richtlinien zur Priorisierung von Repos gibt. Wie man priorisiert, da gibt es viel, aber nichts, mit welcher Zahl man Fremdrepos exakt priorisiert. Außer für Packman. Ist wahrscheinlich nicht so wichtig, zypper dup, Standardprios und jedes Jahr eine neue OpenSuse, anders als Debian Stable. Denke ich jetzt mal.


    Aber gut, ich halte mich an die Hinweise der "Alten Hasen": zypper up genügt, freshplayerplugin installiere ich, vielleicht auch gar kein flash, mit debian habe ich auch keines. Fand erstmal den Konflikt und den Repowechsel lehrreich, deshalb habe ich es noch nicht getan. benutzt habe ich es nicht.


    LG Jana

    Für den Inhalt des Beitrages 95709 haftet ausdrücklich der jeweilige Autor: Jana

    Dann schau doch einfach mal nach, welche Pakete diese 32-bit Abhängigkeiten nachziehen.
    Das kannst du ganz einfach in Yast machen.
    Dazu trägst du einfach den Namen des betreffenden 32-bit Paketes in die Suchmaske ein und setzt noch einen Haken bei der Suchoption RPM Requires.
    So kannst du zumindest eingrenzen, in welcher Ecke der Übeltäter sitzt.

    @ Sauerland: Der Satz von mir in meinem letzten Beitrag "Deshalb wäre es unwahrscheinlich, wenn das geklappt hätte." ist Unsinn, sorry dafür. Es hätte klappen können, habe mir (endlich) den Menüeintrag genau durchgelesen/durchdacht.


    @'Trekkie00: Habe ich mit einigen 32-Bit-Paketen getan:

    Setzt voraus:/bin/sh


    Mehr kommt nicht.


    Ich gebe mich jetzt zufrieden mit ausschließlich zypper up und ausschließlich packman-Priorisierung auf 20, zur Sicherheit hardware mit URL: Index of /repositories/hardware/openSUSE_13.2 auf Prio=120, da so keine OBS-Pakete bei einem versehentlichen zypper dup gezogen werden. Ist letztere Niedrig-Priorisierung aus eurer Sicht vernünftig?


    Sorry für das Nerven, aber korrekte Repos erscheinen mir für eine dauerhafte Funktion des Systems Grundlage. Debian-Erziehung eben. LG Jana

    Einmal editiert, zuletzt von Jana ()

    Für den Inhalt des Beitrages 95773 haftet ausdrücklich der jeweilige Autor: Jana

    Ich würde sogar an deiner Stelle auf das Hardware Repository verzichten, solange es keinen triftigen Grund gibt dieses einzubinden.
    Solange alles funktioniert, ist es eigentlich unnötig und stellt eine weitere potentielle Fehlerquelle dar.


    Falls du dieses allerdings einbinden möchtest, macht deine Priorisierung sehr wohl Sinn.

    Zusammenfassung:


    Wenn das Repo hardware (OBS) aktiv ist, bringt zypper up folgende Meldung aufgrund neurer Pakete in hardware (OBS):
    "Die folgenden 17 Paketaktualisierungen werden NICHT installiert: ... "
    Nach einer Deaktivierung (natürlich nach Installation von TLP) tritt die Meldung nicht mehr auf. Wenn man davon ausgeht, dass jedes Jahr ein Distributionsupgrade erfolgt, kann man wohl gut auf eine eventuelle Aktualisierung verzichten oder man aktiviert von Zeit zu Zeit probeweise das Repo oder man lebt eben mit einer Meldung von zypper up.


    Um den Thread abzuschließen und anderen zu helfen, sollte ja für Leap42.x sinngemäß gelten, nachfolgend die Quintessenz:
    ----------------------------------------------------------------------------------------------------------------
    - Repo packman Prio=20 mit Vendorchange vorher installierter Pakete (einziger empfohlener Anbieterwechsel)
    - Repo hardware (für TLP) Prio=120, bei einem versehentlichen zypper dup erfolgt kein Vendorchange auf Open Bild Service (OBS)
    - Repo hardware deaktivieren, dann bringt zypper up keine Meldung "Die folgenden 17 Paketaktualisierungen werden NICHT installiert ..."
    (In hardware (OBS) befinden sich neuere Paket-Versionen als in Hauptrepo (OSS).)


    zypper up
    Daten des Repositories laden ...
    Installierte Pakete lesen ...
    Die folgenden 17 Paketaktualisierungen werden NICHT installiert:
    acpica android-tools cpupower crda iw libcpupower0 libiw30 libts-1_0-0 libusb-0_1-4 libusb-1_0-0 linuxconsoletools smartmontools usb_modeswitch
    usb_modeswitch-data wireless-regdb wireless-tools wpa_supplicant
    Keine auszuführenden Aktionen.


    zypper lr -uP
    # | Alias | Name | Aktiviert | GPG-Überprüfung | Aktualisieren | Priorität | URI
    ---+------------------------------------+---------------------------------------------------------+-----------+-----------------+---------------+-----------+------------------------------------------------------------------------
    11 | packman | packman | Ja | (r ) Ja | Ja | 20 | Index of /suse/openSUSE_13.2/
    1 | bumblebee | bumblebee | Ja | (r ) Ja | Ja | 99 | Index of /repositories/X11:/Bumblebee/openSUSE_13.2
    2 | download.opensuse.org-13.2-non-oss | Aktualisierungs-Repository (Nicht-Open-Source-Software) | Ja | ( p) Ja | Ja | 99 | Index of /update/13.2-non-oss
    3 | download.opensuse.org-non-oss | Haupt-Repository (NON-OSS) | Ja | ( p) Ja | Ja | 99 | Index of /distribution/13.2/repo/non-oss
    4 | download.opensuse.org-oss | Haupt-Repository (DEBUG) | Nein | ---- | Nein | 99 | Index of /debug/distribution/13.2/repo/oss
    5 | download.opensuse.org-oss_1 | Haupt-Repository (OSS) | Ja | ( p) Ja | Ja | 99 | Index of /distribution/13.2/repo/oss
    6 | download.opensuse.org-oss_2 | Haupt-Repository (Quellen) | Nein | ---- | Nein | 99 | Index of /source/distribution/13.2/repo/oss
    7 | download.opensuse.org-update | Aktualisierungs-Repository (DEBUG) | Nein | ---- | Nein | 99 | Index of /debug/update/13.2
    8 | download.opensuse.org-update_1 | Hauptaktualisierungs-Repository | Ja | (r ) Ja | Ja | 99 | Index of /update/13.2
    10 | libdvdcss | libdvdcss | Nein | ---- | Nein | 99 | http://opensuse-guide.org/repo/13.2/
    12 | repo-debug-update-non-oss | openSUSE-13.2-Update-Debug-Non-Oss | Nein | ---- | Nein | 99 | Index of /debug/update/13.2-non-oss
    13 | virtualbox | virtualbox | Ja | ( p) Ja | Ja | 99 | Index of http://download.virtualbox.org/virtualbox/rpm/opensuse/13.2
    9 | hardware | hardware | Ja | (r ) Ja | Ja | 120 | Index of /repositories/hardware/openSUSE_13.2


    (Repo hardware (OBS) hier noch nicht deaktiviert.)
    ----------------------------------------------------------------------------------------------------


    Danke an die Helfer. LG Jana.

    Für den Inhalt des Beitrages 95794 haftet ausdrücklich der jeweilige Autor: Jana