Bestimmte Pakete nur aus einer Quelle
![](https://seccdn.libravatar.org/avatar/6605d729589fd1ab7ad73b1927fb267c.jpg?s=120&d=mm&r=g)
Hallo, da wir texlive selbst in de rHand haben wollen, sollen bei einem Systemupdate die Pakete nur aus unserer Quelle kommen. Weiß jemand, wei ich festnageln kann, dass er bei einem Systemupdate die txlive-Pakete aus unserer Quelle nimmt, den Rest eben aus den originalen SUSE-Quellen? Gruß Daniel -- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 https://www.marco.de Email ds@marco.de Geschäftsführer Martin Reuter, Torsten Lukas HRB 171775 Amtsgericht München
![](https://seccdn.libravatar.org/avatar/f7ca0d57e6444449cd9c2fbc17e15896.jpg?s=120&d=mm&r=g)
Am 05.01.22 13:15 schrieb Daniel Spannbauer:
Hallo,
da wir texlive selbst in de rHand haben wollen, sollen bei einem Systemupdate die Pakete nur aus unserer Quelle kommen.
Weiß jemand, wei ich festnageln kann, dass er bei einem Systemupdate die txlive-Pakete aus unserer Quelle nimmt, den Rest eben aus den
originalen SUSE-Quellen?
Gruß
Daniel
Ich würde vermuten, mit Hilfe der Repo-Priorität ?? ...
![](https://seccdn.libravatar.org/avatar/ebe9e7470f033d101415722d029f0b24.jpg?s=120&d=mm&r=g)
Hi ich installiere LaTeX direkt aus den texlive quellen (www.ctan.org) nach /usr/local/ und setze den PATH entsprechend so dass /usr/local/bin vor /usr/bin benutzt wird. Dann werden LaTeX &co sowie die .cls/.sty aus texlive und nicht sonst woher genommen. Man hat halt LaTeX doppelt installiert (weil z.B. emacs/auctec tex "nach sich zieht). Aber ok, Plattenplatz ist billig :-) Bye Jürgen Am Mittwoch, 5. Januar 2022, 13:15:45 CET schrieb Daniel Spannbauer:
Hallo,
da wir texlive selbst in de rHand haben wollen, sollen bei einem Systemupdate die Pakete nur aus unserer Quelle kommen.
Weiß jemand, wei ich festnageln kann, dass er bei einem Systemupdate die txlive-Pakete aus unserer Quelle nimmt, den Rest eben aus den
originalen SUSE-Quellen?
Gruß
Daniel
-- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 https://www.marco.de Email ds@marco.de Geschäftsführer Martin Reuter, Torsten Lukas HRB 171775 Amtsgericht München
-- Dr.rer.nat. Jürgen Vollmer, Am Rennbuckel 21, D-76185 Karlsruhe Tel: +49(721) 92 04 87 1 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de
![](https://seccdn.libravatar.org/avatar/11cbbdef6c32c30b9b46c2ea0e281f75.jpg?s=120&d=mm&r=g)
Am 2022-01-05 13:15, schrieb Daniel Spannbauer:
Hallo,
Hallo Daniel,
da wir texlive selbst in de rHand haben wollen, sollen bei einem Systemupdate die Pakete nur aus unserer Quelle kommen.
Weiß jemand, wei ich festnageln kann, dass er bei einem Systemupdate die txlive-Pakete aus unserer Quelle nimmt, den Rest eben aus den
originalen SUSE-Quellen?
Es ist doch so, wenn ich einmal etwas aus einer Quelle installiert habe, wird immer nur diese Quelle für das Paket-Update genutzt. Es sei denn, ich erlaube es explizit. Bedingung dabei ist, man verwendet "zypper up". Nur "zypper dup" wechselt die Quellen. Gruß Reni
![](https://seccdn.libravatar.org/avatar/6605d729589fd1ab7ad73b1927fb267c.jpg?s=120&d=mm&r=g)
Es ist doch so, wenn ich einmal etwas aus einer Quelle installiert habe, wird immer nur diese Quelle für das Paket-Update genutzt. Es sei denn, ich erlaube es explizit. Bedingung dabei ist, man verwendet "zypper up". Nur "zypper dup" wechselt die Quellen.
Gruß Reni
Hallo, updated man Tumbleweed nicht immer mit "zypper dup"? Wir hatten eigentlich vor, Tumbleweed hier zu nutzen. Gruß Daniel
![](https://seccdn.libravatar.org/avatar/fe9ad51277ab246de267f489d6ecf157.jpg?s=120&d=mm&r=g)
Am Freitag, 7. Januar 2022, 09:11:20 CET schrieb reni@vivaldi.net:
Guten Morgen,
Am 2022-01-07 08:34, schrieb Daniel Spannbauer:
updated man Tumbleweed nicht immer mit "zypper dup"? Wir hatten eigentlich vor, Tumbleweed hier zu nutzen.
Dann sollte man das in der Fragestellung auch erwähnen ...!
+1 Und in dem Falle arbeite man mit locks und repo prioritäten. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on liberachat and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
![](https://seccdn.libravatar.org/avatar/6605d729589fd1ab7ad73b1927fb267c.jpg?s=120&d=mm&r=g)
Am 07.01.2022 um 09:26 schrieb Mathias Homann:
Am Freitag, 7. Januar 2022, 09:11:20 CET schrieb reni@vivaldi.net:
Guten Morgen,
Am 2022-01-07 08:34, schrieb Daniel Spannbauer:
updated man Tumbleweed nicht immer mit "zypper dup"? Wir hatten eigentlich vor, Tumbleweed hier zu nutzen.
Dann sollte man das in der Fragestellung auch erwähnen ...! +1
Und in dem Falle arbeite man mit locks und repo prioritäten.
Greifen Repo-Prios auch, wenn neuere Pakete verfügbar sind? Die Pakete unseres Repos hätten ja ältere Versionen als die, die im offiziellen Repo verfügbar sind. Oder gehen die Prios nur auf den Paket-Namen? Gruß Daniel
![](https://seccdn.libravatar.org/avatar/fe9ad51277ab246de267f489d6ecf157.jpg?s=120&d=mm&r=g)
Am Freitag, 7. Januar 2022, 09:39:41 CET schrieb Daniel Spannbauer:
Am 07.01.2022 um 09:26 schrieb Mathias Homann:
Und in dem Falle arbeite man mit locks und repo prioritäten.
Greifen Repo-Prios auch, wenn neuere Pakete verfügbar sind?
Die Pakete unseres Repos hätten ja ältere Versionen als die, die im offiziellen Repo verfügbar sind.
Oder gehen die Prios nur auf den Paket-Namen?
Wenn in einem Repo mit höherer Prio eine ältere Version liegt als in einem Repo mit niedriegerer Prio, sagt Zypper "Ich hab hier ein update für X aber die repo priorität ist niedriger, das muss manuell installiert werden." Am besten kombiniert man das dann mit packetsperren. Wenn du beim sperren ein repo mit angibst, heisst das ja dann "das paket soundso AUS DEM REPO X soll nicht geändert werden" - und wenn das paket soundso aus einem anderen repo installiert wurde, bedeutet das effektiv dass du "soundso aus repo X ist verboten" sagst, aber eben nur aus dem speziellen repo. Wenn du also z.b. den Fall hast, dass du ...sagenwirmal blender sowohl von opensuse als auch von packman bekommen kannst, du aber beides nicht willst und blender statt dessen aus einem eigenen repo kommt, musst du beide versionen sperren, also die aus packman und die aus opensuse, und dann noch sicherstellen dass das eigene repo die höchste prio hat - also bei "zypper mr -p" eine schön kleine nummer angeben. Bei mir sieht das auf Tumbleweed so aus: https://paste.opensuse.org/25992142 zypper lr -P sortiert die repos nach priorität, ist bei solchen bastelarbeiten recht nützlich. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on liberachat and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
![](https://seccdn.libravatar.org/avatar/b58101fb24c64d0ff1d0f918e61cedd2.jpg?s=120&d=mm&r=g)
Hallo Daniel, hallo zusammen, Am Freitag, 7. Januar 2022, 09:39:41 CET schrieb Daniel Spannbauer:
Am 07.01.2022 um 09:26 schrieb Mathias Homann:
Am Freitag, 7. Januar 2022, 09:11:20 CET schrieb reni@vivaldi.net:
Am 2022-01-07 08:34, schrieb Daniel Spannbauer:
updated man Tumbleweed nicht immer mit "zypper dup"? Wir hatten eigentlich vor, Tumbleweed hier zu nutzen.
Richtig, bei Tumbleweed sollte man immer "zypper dup" benutzen. Es kommt aber noch ein anderer Parameter ins Spiel: --allow-vendor-change Ein halbwegs aktuelles Tumbleweed hat (seit mindestens 1-2 Jahren) in /etc/zypp/zypp.conf standardmäßig # solver.allowVendorChange = false (ja, das ist auskommentiert, aber "false" ist auch der Default). Bereits installierte Pakete werden also nur vom gleichem Vendor aktualisiert (oder eben auch nicht aktualisiert), selbst wenn es in einem Repo mit höherer Priorität ein neueres Paket gibt.
Und in dem Falle arbeite man mit locks und repo prioritäten.
Locks sollten zum Festlegen des Repos nicht nötig sein, sondern nur um - die Installation eines "recommended"-Pakets zu verhindern - ein Paket auf eine exakte Version festzunageln (z. B. weil das Update einen bekannten Bug hat) Zu Prioritäten:
Greifen Repo-Prios auch, wenn neuere Pakete verfügbar sind?
Die Pakete unseres Repos hätten ja ältere Versionen als die, die im offiziellen Repo verfügbar sind.
Oder gehen die Prios nur auf den Paket-Namen?
Repo-Prioritäten greifen (AFAIK: nur), wenn Du ein neues (noch nicht installiertes) Paket installierst. Bei Updates von bereits installierten Paketen bleibt zypper beim Ursprungs-Vendor. (Mit zypper dup --allow-vendor-change wird natürlich der Vendor gewechselt, aber das willst Du ja dann so. Der Vollständigkeit halber, und hoffentlich nicht zu verwirrend: Ich habe oben immer wieder "Repo" und "Vendor" verwendet. Das sind zwei verschiedene Dinge. Ein Repo ist z. B. das oss-Repo oder das update- Repo, ein "Vendor" kann z. B. "openSUSE" oder "home:cboltz" (für mein Home-Repo) sein. Eigentlich hätte ich immer den Begriff "Vendor" benutzen müssen, weil zypper (unabhängig vom Repo) nur da drauf guckt. Mehrere Repos können Pakete mit identischem Vendor haben (z. B. oss und update). In diesem Fall erfolgt stillschweigend ein Repo-Wechsel eines Pakets bei gleichem Vendor. Wäre ja auch nervig, wenn man fürs Installieren von Sicherheitsupdates auch noch --allow-vendor-change braucht ;-) Und um die Sache nochmal spannender zu machen, kann man zwei Vendor- Namen auch als gleich behandeln lassen - bei Leap ist das z. B. "SUSE" und "openSUSE". Gruß Christian Boltz -- Just assume that all the people who don't reply agree, with a +1. If they disagree, they should raise their voices with an argument. When there's no argument left, it means we all agree. [Vincent Untz in opensuse-foundation]
participants (6)
-
Christian Boltz
-
Daniel Spannbauer
-
Dr. Jürgen Vollmer
-
Mathias Homann
-
Norbert Zawodsky
-
reni@vivaldi.net