Hallo Michael, Am Mittwoch, 25. März 2015, 20:30:15 schrieb blue hut:
Hallo Liste! Ich hab wiedereinmal ne Menge Fragen:
1. Da ich relativ neu bei openSUSE bin und davor immer rolling release distros hatte (debian testing/Gentoo) wollte ich gerne wissen ob ein dist-upgrade ohne Probleme immer läuft? Also nur repos anpassen und dist-upgrade ausführen oder? Können irgendwelche altlasten passieren? Dateien die nicht mehr gebraucht werden übrig bleiben? Sonst irgendwelche Paketverwirrungen? (Zwecks Entscheidung zwischen Tumbleweed und versioniert)
Ich selber nutz seit einiger Zeit Tumbleweed. Davor habe ich Distributionsaktualisierungen aber jedes Mal neu installiert, was meiner Meinung nach mit einer separaten Home-Partition ziemlich schmerzfrei ist und schnell von der Hand geht. Die Entscheidung zur Neuinstallation fußte allerdings nie auf schlechten Erfahrungen mit kompletten online dist-upgrades. Das habe ich schlichtweg einfach nie probiert. :) Als Faustformel kann man aber sicherlich davon ausgehen, dass die Komplexität einer Aktualisierung mit der anzahl der genutzten externen Paketdepots ansteigt. Ohne mich jetzt zu weit aus dem Fenster lehnen zu wollen, da ich es wie gesagt nie ausprobiert habe, würde ich für eine Aktualisierung ohne neuinstallation alle anderen Depots außer den Basis-Depots deaktivieren. Aber damit haben andere sicherlich mehr Erfahrung.
2. Dann wollte ich gerne wissen ob der openSUSE Kernel irgendwelche patches hat die ihn von Vanilla unterscheiden, wollte gerne wissen wo ich das herausfinden kann. Somit würde ich gerne herausfinden was in openSUSE denn beser funktioniert oder besser unterstützt wird als in anderen Distros.
Keine Ahnung, ob es dazu irgendwo schön aufbereitete Informationen, bspw. im Wiki, gibt. Einen groben Überblick kann man sich aber auf jeden Fall im Build Service verschaffen. Hier bspw. für openSUSE Factory: https://build.opensuse.org/package/show/openSUSE:Factory/kernel-source
3. Repos: Ich habe folgende repos: # | Alias | Name | Enabled | Refresh ---+-------------------------------+---------------------------------------+ ---------+--------
1 | Atlassian HipChat | Atlassian HipChat | Yes | Yes 2 | download.opensuse.org-non-oss | Main Repository (NON-OSS) | Yes | Yes 3 | download.opensuse.org-oss | Main Repository (OSS) | Yes | Yes 4 | home_jubalh | jubalh's Home Project (openSUSE_13.2) | Yes | Yes 5 | openSUSE-13.2-0 | openSUSE-13.2-0 | Yes | Yes 6 | packman-essentials | packman-essentials | Yes | Yes 7 | packman-multimedia | packman-multimedia | Yes | Yes 8 | repo-debug | openSUSE-13.2-Debug | No | Yes 9 | repo-debug-update | openSUSE-13.2-Update-Debug | No | Yes 10 | repo-debug-update-non-oss | openSUSE-13.2-Update-Debug-Non-Oss | No | Yes 11 | repo-source | openSUSE-13.2-Source | No | Yes 12 | repo-update | openSUSE-13.2-Update | Yes | Yes 13 | repo-update-non-oss | openSUSE-13.2-Update-Non-Oss | Yes | Yes
bei einigen habe ich keine Ahnung was sie tun. Das wären z.b. 2,3,5,8-13. Ich nehme an 5 ist das offizielle repo für 13.2. Oder wären das 2 und 3? repo-debug bringt mir vll debug infos zu Paketen falls ich die brauche? Doch wozu soll dann debug-update sein? Selbiges mit source. Verwirrung
1 und 4 scheinst du ja selber hinzugefügt zu haben. 5 sieht nach einem Installationsmedium wie einer DVD oder einem USB-Stick aus. 3 ist das offizielle Hauptdepot für quelloffene Software. 2 ist dementsprechend das offizielle Depot für nich quelloffene Software. 12 enthält die Updates für quelloffene Software, 13 die für nich quelloffene Software. Wie du schon richtig vermutet hast, enthalten die debug-Depots die zur Software gehörenden Debuginfo-Pakete. Source dann halt die Quellen. Warum nun diese Trennung? Die Trennung von Debuginfo- und Source-Depots hält die Meta-Informationen der Standarddepots etwas kleiner. Die wenigsten Nutzer benötigen diese Pakete wirklich. Die Trennung zwischen nicht quelloffen und quelloffen sorgt dafür, dass Nutzer, die partout nicht mit proprietärer Software in Berührung kommen wollen, sich von dieser verschonen lassen können. ;)
4. Warum muss ich für verschiedene openSUSE/SLES verschiedene rpms bauen? Hier bitte ausführlich am besten mit Beispiel was auftrit das dies notwendig ist. Ich dachte solange der Architekturtyp passt, ist alles ok? Oder gibt es zwischen den openSUSE Versionen Änderungen wo config Dateien liegen usw.? Dies wird sicher nicht oft vorkommen und deshalb sollten die meistne rpms doch auch unter anderen Versionen laufen, oder nicht?
Es sind ja nicht nur die Architektur und möglicherweise der Ort, an dem die Konfigurationsdateien gespeichert werden. Viel wichtiger sind die vielfältigen Beziehungen der Pakete untereinander. Es kann schon sein, dass mal etwas läuft, dass eigentlich für eine andere Distribution oder Distributionsversion erstellt wurde. Sauberer ist es aber, Pakete für genau die Umgebung zu erstellen, in der sie gentutz werden. Genau das erledigt auch der Build Service. Neue Softwareversionen können auch immer wieder Schnittstellen ändern oder andere Inkomaptibilitäten mit sich bringen. Wodurch dann wiederum Software, die darauf aufbaut, nicht mehr funktioniert.
Und wie sieht das mit Fedora/RedHat aus? Überhaupt nicht kompatibel? Hilft es da ein source rpm zu haben, und aus dem lassen sich dann rpms für alle bauen?
Aus oben genannten Gründen nicht so ohne weiteres. Aber das src-RPM wäre dann schon der richtige Weg, zumindest wenn die SPEC-Datei so geschrieben ist, dass sie in verschiedenen Distributionen funktioniert. ;)
Ich hoff ihr könnt mir hier etwas weiter helfen. Wenns geht gerne ausführlich
Joa, immer wieder gerne, aber schau auch einfach mal im openSUSE Wiki vorbei. ;)
Viele Grüße Michael
Beste Grüße Buschmann -- Das Gesetz hat zum Schneckengang verdorben, was Adlerflug geworden wäre. (Friedrich Schiller - Die Räuber) Und der Buschfunk spielt gerade "Stars And Stripes" von "Anti-Flag". www.buschmann23.de GPG-Key: 0x614C3258 GPG Fingerprint: B770 E0D0 69CF BFC1 5FE1 D78E 3A70 A936 614C 3258