Hallo.
Vorab: Ich nutze SmartPM und habe dazu einige Fragen an die Experten unter Euch, die sich auch mit den Repositories auskennen.
Ich heisse Kai und habe mich eben in diesem Forum neu angemeldet. Das Forum nutze ich schon lange als stiller Leser und finde es hervorragend. Dafür möchte ich mich bei den Administratoren dieses Forums bedanken und auch bei den Nutzern für die vielen schönen Beiträge.
Linux, genauer Suse Linux, nutze ich hingegen schon einige Jahre.
Z.Zt. OpenSuse OSS-Factory 10.1 (i386), KDE 3.5.1.x, Kernel 2.6.x
Zur Situation:
Als Paketmanager habe ich unter Suse seit Jahren APT benutzt. Damit habe ich stets mein System aktualisiert und auch auf neue KDE-Versionen aktualisiert, sogar immer aus dem laufenden Betrieb heraus. Seit kurzem habe ich Smart entdeckt. Ich habe viel über Smart gelesen, FAQs, Forenbeiträge, etc. und weiss eigentlich, wie Smart funktioniert und wie man es benutzt. Allerdings fehlt mir ganz bestimmtes Hintergrundwissen über die Repositories und Systemupgrades bei Suse, was ich nirgendwo nachlesen konnte.
Auf meinem Rechner habe ich letztens OpenSuse 10.1-RC2 via. 5-CD-Set (ISO-Images gebrannt) neu installiert. Dann habe ich mittels Smart mein System auf die aktuelle Entwicklerversion SL-OSS-Factory 10.1 aktualisiert. Bevor ich weiter schreibe, poste ich hier mal meine Channels und Mirrors, damit es keine Missverständnisse gibt:
Meine Channel-Liste:
Meine Mirror-Liste
So bin ich beim Upgrade von RC2 auf die aktuelle Entwicklerversion SL-OSS-Factory vorgegangen:
1)
Ausgehend von einem installierten OpenSuse 10.1-RC2 starte ich 'smart --gui' als root und aktualisiere zunächst alle Channel (Update).
2)
Um das Basis-System (RC2) auf die aktuelle SL-OSS-Factory Entwicklerversion zu aktualisieren, deaktiviere ich in der GUI alle Channel (Base, Packman, Guru, etc.) bis auf RPM-SYS (Lokale Paketdatenbank) und den [opensuse-sl-oss-factory_yast2] Channel.
3)
Nun wähle ich in der GUI 'Bearbeiten/Aktualisiere alles' (also Upgrade). In der folgenden Zusammenfassung kontrolliere ich nochmal manuell, ob mir irgendetwas schräges auffällt und lasse Smart dann den Rest machen. Danach boote ich den Rechner.
Nun habe ich einige generelle Fragen:
A)
Ist es richtig, dass auf den FTP-Servern in dem Verzeichnis 'sl-oss-factory' stets ein tagesaktueller Snapshot der aktuellen Entwicklerversion vorzufinden ist?
B)
Ist es richtig, dass die Release-Kandidaten RC1, RC2 und RC3 jeweils Snapshots dieser SL-OSS-Factory Version sind?
Wenn ich also auf einem OpenSuse 10.1-RC2 System nach dem offiziellen Erscheinen des 10.1-RC3 ein Upgrade mittels Smart gemacht habe, bin ich dann auch automatisch auf dem Mindeststand der RC3?
C)
Wie kann ich bei Suse Linux feststellen, welche exakte Versionnummer das Basis-System hat, also ob z.B. 10.1-RC1, RC2, Factory, etc. installiert ist? Die maximale Information die ich bekommen kann, ist dass Version 10.1 installiert ist.
D)
Dies ist mir besonders wichtig:
Wie werden Neuerungen von einem Versionsübergang z.B. von 10.0 auf 10.1 bei einem Upgrade sei es direkt durch Yast oder andere Paketmanager wie z.B. Smart gehandhabt?
Mal angenommen ich upgrade von einer installierten 10.0-Final auf eine 10.1-Final. Der Networkmanager ist dabei ein gutes Beispiel. In 10.0 gab es z.B. keinen Networkmanager. BTW, ich weiss, dass der Networkmanager noch gravierende Mängel hat. Angenommen er funktioniert in der 10.1-Final einwandfrei und würde standardmäßig installiert/aktiviert werden. Ist der Networkmanager nach einem Upgrade durch Smart und Co. von 10.0 auf die 10.1 automatisch aktiviert? Ich glaube nicht.
Ich denke, wenn man sein System mittels Smart und Co. auf eine nächst höhere Version upgradet, muss man ggf. doch auf bestimmte Neuerungen verzichten. Smart analysiert die installierten Pakete der installierten 10.0 Version und schaut, ob in den Repositories neuere Versionen liegen. Diese werden dann runtergeladen und die lokal installierten Pakete damit ersetzt. Wenn aber ein Paket wie z.B. der Networkmanager bei der 10.0 nicht installiert war, weil es den Networkmanager in 10.0 noch nicht gab, wird Smart den Networkmanager bei einem Upgrade von 10.0 auf 10.1 doch denke ich nicht installieren, obwohl dieser in einer Standardinstallation von 10.1 installiert worden wäre. Wenn man also nicht weiss, dass es in der 10.1 einen Networkmanager gibt, wird man wohl trotz Online-Upgrade via Smart und Co. auf die neue 10.1 diese Feature nicht nutzen können, weil es nicht installiert wird. Sehe ich dies richtig? Der Networkmanager soll nur ein Beispiel sein. Wenn man also solche 'neuen Funktionen' einer Distribution auch nutzen möchte, sollte man dann nicht doch besser ein System-Update per Yast oder noch besser eine Neuinstallation wählen, als 'nur' ein Upgrade per Smart und Co. zu machen, weil einem ansonsten viel schöne neue Funktionalität durch die Lappen gehen könnte (überspitzt ausgedrückt)? Dies ist nur ein Beispiel, denn woher soll ich wissen, welche Pakete ist zusätzlich zu meinem Online-Upgrade installieren soll, damit mein System den Funktionsumfang hat, als wenn ich eine Neuinstallation der neuen Version wählen würde, wo dann bestimmte Pakete standardmäßig installiert werden?
Ein anderes Beispiel wäre, wenn bei einem Versionswechsel z.B. von 10.0 auf 11.0 gravierende Änderungen in der Distribution vorgenommen werden, wie z.B. Ersetzung des Paketsystem durch ein anderes Paketsystem. Müsste ein Upgrade via Smart und Co. dort nicht zwangsweise scheitern?
Die Frage ist, ob es nicht generell besser ist, bei einer neuen Version stets eine Neuinstallation zu fahren..!?!?
Dies würde meiner Meinung nach auf auf neue KDE-Versionen zutreffen. Angenommen ich update von KDE3.5 auf später KDE4. KDE4 wird gravierende Neuerungen haben. Evtl. wird ein Update per Smart möglich sein. Aber ist mein System nach einem Neustart dann so, als wenn ich KDE komplett neu installiert hätte? Würden dann nicht evtl. einige Pakete nicht mitinstalliert werden bzw. würden sich nicht alte vorhandene Konfigurationsdateien störend auswirken? Eine neue KDE Version hat u.U. ein noch genialeres Look&Feel als eine vorher installierte, ältere Version. Auf dieses Look&Feel würde ich dann verzichten müssen, weil nach dem Update auf die neue KDE-Version eben doch noch die alten Konfigurationsdateien verwendet werden. Klar kann man bei der neuen Version alle Einstellungen manuell ändern, aber darum geht es mir nicht.
Machen also Online-Updates via Smart nicht deshalb nur Sinn bei kleinen Versionssprüngen, z.B. OpenSuse 10.0RC2 auf 10.0RC3 oder KDE 3.5.0 -> 3.5.1? Beim Übergang von OpenSuse 10.0 auf 10.1 gibt es ja schon gravierende Änderungen (Paketdatenbank, Networkmanager,..).
Es geht mir also nicht um technische Probleme beim upgraden auf eine nächst höhere Version, sondern nur um die Funktionalität bzw. neue Funktionen.
E)
Bei den diversen FTP-Servern bzw. Mirrors existiert eine teilweise unterschiedliche Verzeichnisstruktur, was die Repositories angeht.
Wie kann man die einzlenen Repository-Verzeichnisse bzw. Typen in der Verzeichnisstruktur der FTP-Server bzgl. Smart unterscheiden?
type=yast2: Dies ist eine Yast-Installationsquelle.
Kennzeichnend dafür ist das Vorhandensein einer 'directory.yast' Datei. Richtig?
type=apt-md: Dies ist eine Yum Quelle für RPM-Metadaten.
Kennzeichnend dafür ist das Vorhandensein der beiden Verzeichnisse 'repodata' und 'rpm'. Richtig?
type=apt-rpm: Dies ist ein APT-Repository.
Hier muss ein Verzeichnis 'base' sowie weitere Verzeichnisse 'RPMS.blabla' existieren. Richtig
F)
Im APT Repository für die Opensuse 10.1 gibt es ein Verzeichnis 'RPMS.base'. Was genau stellt dieses Verzeichnis in den APT-Repositories dar? Liegen in diesem Verzeichnis später mal alle Pakete, die auch auf den CDs der Final-Version vorzufinden sind? Ist dieses APT-Repository im Prinzip ein Abbild der Pakete der jeweiligen Finalversion?
Stellt dann 'RPMS.update' das APT-Repository-Äquivalent der Suse-Updates bereit, die man auch über Suse YOU einspielen kann?
G)
Angenommen ich möchte via Smart ein Ugrade von 10.0 auf die 10.1 Final durchzuführen.
In meiner Channel-Liste steht natürlich noch folgender Factory Channel:
Reicht es nun aus, diesen Channel zu entfernen und dann folgenden Channel hinzuzufügen?
Was passiert, wenn man beide Channel parallel aktiviert?
H)
Kann man unter der 10.1 OSS-Factory auch einen Channel für das APT KDE-Repository der OSS-10.0 hinzufügen oder handelt man sich Probleme ein?
Die Factory hat z.B. KDE 3.5.1.x, wahrend im KDE-Repository für 10.0-OSS KDE 3.5.2.x liegt.
Eigentlich müsste das doch keine Probleme machen, oder sind die KDE 3.5.1 Pakete der Factory-Version anders gebaut, als die Pakete der OSS-10.0 Version?
Eine Menge Fragen. Vielleicht profitieren von evtl. Antworten auch andere Leute.
Am liebsten wäre mir, wenn Ihr zu den einezlnen Punkten A) B) oder E) separat kurz antworten würdet.
Herzlichen Dank dafür.
Ansonsten komme ich mit Smart gut zurecht. Mein System läuft trotz der Probleme mit dem Networkmanager sehr gut und ich kann mein gesamtes System inkl. Kernel, KDE, etc. im laufenden Betrieb unter KDE komplett aktualisieren. Danach booten und alles ist prima. Natürlich habe ich mein Sytsem auch mal zerschossen. Aber dies stellt an sich klein Problem für mich da. Das bekomme ich meist irgendwie immer wieder ans Laufen. Smart ist toll, jedoch finde ich es grotten langsam. Damit aber kann ich gut leben. Das letzte Gesamtupdate hat doch glatt 2,3GB RPMs runtergeladen, mein gesamtes System aktualisiert und danach hat alles einwandfrei funktioniert.
LG, Kai
Vorab: Ich nutze SmartPM und habe dazu einige Fragen an die Experten unter Euch, die sich auch mit den Repositories auskennen.
Ich heisse Kai und habe mich eben in diesem Forum neu angemeldet. Das Forum nutze ich schon lange als stiller Leser und finde es hervorragend. Dafür möchte ich mich bei den Administratoren dieses Forums bedanken und auch bei den Nutzern für die vielen schönen Beiträge.
Linux, genauer Suse Linux, nutze ich hingegen schon einige Jahre.
Z.Zt. OpenSuse OSS-Factory 10.1 (i386), KDE 3.5.1.x, Kernel 2.6.x
Zur Situation:
Als Paketmanager habe ich unter Suse seit Jahren APT benutzt. Damit habe ich stets mein System aktualisiert und auch auf neue KDE-Versionen aktualisiert, sogar immer aus dem laufenden Betrieb heraus. Seit kurzem habe ich Smart entdeckt. Ich habe viel über Smart gelesen, FAQs, Forenbeiträge, etc. und weiss eigentlich, wie Smart funktioniert und wie man es benutzt. Allerdings fehlt mir ganz bestimmtes Hintergrundwissen über die Repositories und Systemupgrades bei Suse, was ich nirgendwo nachlesen konnte.
Auf meinem Rechner habe ich letztens OpenSuse 10.1-RC2 via. 5-CD-Set (ISO-Images gebrannt) neu installiert. Dann habe ich mittels Smart mein System auf die aktuelle Entwicklerversion SL-OSS-Factory 10.1 aktualisiert. Bevor ich weiter schreibe, poste ich hier mal meine Channels und Mirrors, damit es keine Missverständnisse gibt:
Meine Channel-Liste:
Code:
[opensuse-sl-oss-factory_yast2]
type = yast2
name = OpenSuse Linux 10.1 - SL-OSS-Factory (YAST2)
baseurl = ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/inst-source/
[suse-extra_yast2]
type = yast2
name = Suse Linux 10.1 - Extra (YAST2)
baseurl = ftp://ftp.gwdg.de/pub/suse/install/10.1/inst-source-extra/
[suse-packman_yast2]
type = yast2
name = Suse Linux 10.1 - Packman (YAST2)
baseurl = http://packman.iu-bremen.de/suse/10.1/
[guru_yum]
type = rpm-md
name = Suse Linux 10.1 - Guru (YUM)
baseurl = http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.1/RPMS/
[suse-update_yum]
type = rpm-md
name = Suse Linux 10.1 - Update (YUM)
baseurl = ftp://ftp.suse.com/pub/suse/i386/update/10.1/
[suse-base_apt]
type = apt-rpm
name = Suse Linux 10.1 - Base (APT)
baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
components = base
[suse-extra_apt]
type = apt-rpm
name = Suse Linux 10.1 - Extra (APT)
baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
components = extra
[suse-kolab_apt]
type = apt-rpm
name = Suse Linux 10.1 - Kolab (APT)
baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
components = kolab
[suse-packmani686_apt]
type = apt-rpm
name = Suse Linux 10.1 - Packman-i686 (APT)
baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
components = packman-i686
[suse-packman_apt]
type = apt-rpm
name = Suse Linux 10.1 - Packman (APT)
baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
components = packman
[suse-security_apt]
type = apt-rpm
name = Suse Linux 10.1 - Security (APT)
baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
components = security
[suse-update_apt]
type = apt-rpm
name = Suse Linux 10.1 - Update (APT)
baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
components = update
[suse-rpmkeys_apt]
type = apt-rpm
name = Suse Linux 10.1 - RPMKeys (APT)
baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
components = rpmkeys
Meine Mirror-Liste
Code:
ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/
ftp://ftp.uni-heidelberg.de/pub/linux/opensuse/distribution/SL-OSS-factory/
ftp://ftp.tu-chemnitz.de/pub/linux/opensuse/distribution/SL-OSS-factory/
ftp://ftp.heanet.ie/mirrors/ftp.opensuse.org/opensuse/distribution/SL-OSS-factory/
http://linux.integrity.hu/pub/opensuse/distribution/SL-OSS-factory/
ftp://mandril.creatis.insa-lyon.fr/linux/opensuse/distribution/SL-OSS-factory/
ftp://ftp.fi.muni.cz/pub/linux/opensuse/distribution/SL-OSS-factory/
ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.1-OSS/
ftp://sunsite.rwth-aachen.de/pub/comp/Linux/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.tu-ilmenau.de/Mirrors/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.rz.uni-ulm.de/pub/mirrors/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.man.poznan.pl/pub/linux/opensuse/distribution/SL-10.1-OSS/
ftp://gd.tuwien.ac.at/linux/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.belnet.be/mirror/ftp.opensuse.org/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.skynet.be/pub/ftp.opensuse.org/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.tu-cottbus.de/pub/unix/linux/opensuse/distribution/SL-10.1-OSS/
ftp://mirrors.netbg.com/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.uni-erlangen.de/mirrors/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.rz.uni-wuerzburg.de/pub/linux/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.uniroma2.it/Linux/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.jaist.ac.jp/pub/Linux/opensuse/distribution/SL-10.1-OSS/
ftp://mirror.switch.ch/mirror/opensuse/distribution/SL-10.1-OSS/
ftp://ftp.suse.com/pub/suse/i386/update
ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/suse/i386/update/
ftp://ftp.tu-ilmenau.de/Mirrors/ftp.suse.com/i386/update/
ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/suse/i386/update/
ftp://ftp.uni-bremen.de/pub/mirrors/suse/i386/update/
ftp://ftp.tu-chemnitz.de/pub/linux/suse/ftp.suse.com/suse/i386/update/
ftp://ftp.tu-cottbus.de/pub/unix/linux/suse.com/suse/i386/update/
ftp://linux.mathematik.tu-darmstadt.de/pub/linux/distributions/suse/ftp.suse.com/suse/i386/update/
ftp://ftp.uni-erlangen.de/pub/Linux/MIRROR.suse/pub/suse/i386/update/
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.suse.com/pub/suse/i386/update/
http://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.suse.com/pub/suse/i386/update/
ftp://ftp.rrzn.uni-hannover.de/pub/mirror/linux/suse/i386/update/
ftp://ftp.hosteurope.de/mirror/ftp.suse.com/pub/suse/i386/update/
http://ftp.hosteurope.de/mirror/ftp.suse.com/pub/suse/i386/update/
ftp://ftp.uni-rostock.de/pub/systems/unix/linux/suse/i386/update/
ftp://ftp.rz.uni-ulm.de/pub/mirrors/suse/i386/update/
ftp://mirror.switch.ch/mirror/SuSE/suse/i386/update/
http://packman.iu-bremen.de/suse/
ftp://ftp.mb3.tu-chemnitz.de/mirrors/packman.iu-bremen.de/suse/
ftp://ftp.cesnet.cz/MIRRORS/packman.iu-bremen.de/suse/
http://packman.rsync.zmi.at/suse/
ftp://packman.rsync.zmi.at/suse/
http://mirror.geht-schon.de/packman.links2linux.de/suse/
http://ftp.uni-erlangen.de/pub/mirrors/packman/suse/
ftp://ftp.uni-erlangen.de/pub/mirrors/packman/suse/
http://packman.mirrors.skynet.be/pub/packman/suse/
ftp://packman.mirrors.skynet.be/pub/packman/suse/
http://ftp.gwdg.de/pub/linux/misc/packman/suse/
ftp://ftp.gwdg.de/pub/linux/misc/packman/suse/
http://packman.inode.at/suse/
ftp://packman.inode.at/suse/
http://packman.unixheads.com/suse/
ftp://packman.unixheads.com/suse/
ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/
http://ftp.gwdg.de/pub/linux/suse/apt/SuSE/
ftp://mirrors.mathematik.uni-bielefeld.de/pub/linux/suse/apt/SuSE/
ftp://ftp.uni-erlangen.de/pub/Linux/MIRROR.suse/apt/SuSE
http://ftp.rz.tu-bs.de/pub/mirror/SuSE/apt/SuSE/
ftp://ftp.heanet.ie/mirrors/gwdg.de/pub/linux/suse/apt/SuSE
ftp://ftp.tu-chemnitz.de/pub/linux/suse/apt/SuSE
ftp://ftp.uni-oldenburg.de/linux/ftp.suse.com/apt/SuSE/
ftp://ftp.sunsite.org.uk/sites/ftp.gwdg.de/SuSE/apt/SuSE/
http://fau.pdacentral.com/pub/mirrors/suse/apt/SuSE/
ftp://ftp.linux.ee/mount/hdd/mirror/suse/apt/SuSE/
ftp://ftp.kde.org/pub/suse/apt/SuSE/
So bin ich beim Upgrade von RC2 auf die aktuelle Entwicklerversion SL-OSS-Factory vorgegangen:
1)
Ausgehend von einem installierten OpenSuse 10.1-RC2 starte ich 'smart --gui' als root und aktualisiere zunächst alle Channel (Update).
2)
Um das Basis-System (RC2) auf die aktuelle SL-OSS-Factory Entwicklerversion zu aktualisieren, deaktiviere ich in der GUI alle Channel (Base, Packman, Guru, etc.) bis auf RPM-SYS (Lokale Paketdatenbank) und den [opensuse-sl-oss-factory_yast2] Channel.
3)
Nun wähle ich in der GUI 'Bearbeiten/Aktualisiere alles' (also Upgrade). In der folgenden Zusammenfassung kontrolliere ich nochmal manuell, ob mir irgendetwas schräges auffällt und lasse Smart dann den Rest machen. Danach boote ich den Rechner.
Nun habe ich einige generelle Fragen:
A)
Ist es richtig, dass auf den FTP-Servern in dem Verzeichnis 'sl-oss-factory' stets ein tagesaktueller Snapshot der aktuellen Entwicklerversion vorzufinden ist?
B)
Ist es richtig, dass die Release-Kandidaten RC1, RC2 und RC3 jeweils Snapshots dieser SL-OSS-Factory Version sind?
Wenn ich also auf einem OpenSuse 10.1-RC2 System nach dem offiziellen Erscheinen des 10.1-RC3 ein Upgrade mittels Smart gemacht habe, bin ich dann auch automatisch auf dem Mindeststand der RC3?
C)
Wie kann ich bei Suse Linux feststellen, welche exakte Versionnummer das Basis-System hat, also ob z.B. 10.1-RC1, RC2, Factory, etc. installiert ist? Die maximale Information die ich bekommen kann, ist dass Version 10.1 installiert ist.
D)
Dies ist mir besonders wichtig:
Wie werden Neuerungen von einem Versionsübergang z.B. von 10.0 auf 10.1 bei einem Upgrade sei es direkt durch Yast oder andere Paketmanager wie z.B. Smart gehandhabt?
Mal angenommen ich upgrade von einer installierten 10.0-Final auf eine 10.1-Final. Der Networkmanager ist dabei ein gutes Beispiel. In 10.0 gab es z.B. keinen Networkmanager. BTW, ich weiss, dass der Networkmanager noch gravierende Mängel hat. Angenommen er funktioniert in der 10.1-Final einwandfrei und würde standardmäßig installiert/aktiviert werden. Ist der Networkmanager nach einem Upgrade durch Smart und Co. von 10.0 auf die 10.1 automatisch aktiviert? Ich glaube nicht.
Ich denke, wenn man sein System mittels Smart und Co. auf eine nächst höhere Version upgradet, muss man ggf. doch auf bestimmte Neuerungen verzichten. Smart analysiert die installierten Pakete der installierten 10.0 Version und schaut, ob in den Repositories neuere Versionen liegen. Diese werden dann runtergeladen und die lokal installierten Pakete damit ersetzt. Wenn aber ein Paket wie z.B. der Networkmanager bei der 10.0 nicht installiert war, weil es den Networkmanager in 10.0 noch nicht gab, wird Smart den Networkmanager bei einem Upgrade von 10.0 auf 10.1 doch denke ich nicht installieren, obwohl dieser in einer Standardinstallation von 10.1 installiert worden wäre. Wenn man also nicht weiss, dass es in der 10.1 einen Networkmanager gibt, wird man wohl trotz Online-Upgrade via Smart und Co. auf die neue 10.1 diese Feature nicht nutzen können, weil es nicht installiert wird. Sehe ich dies richtig? Der Networkmanager soll nur ein Beispiel sein. Wenn man also solche 'neuen Funktionen' einer Distribution auch nutzen möchte, sollte man dann nicht doch besser ein System-Update per Yast oder noch besser eine Neuinstallation wählen, als 'nur' ein Upgrade per Smart und Co. zu machen, weil einem ansonsten viel schöne neue Funktionalität durch die Lappen gehen könnte (überspitzt ausgedrückt)? Dies ist nur ein Beispiel, denn woher soll ich wissen, welche Pakete ist zusätzlich zu meinem Online-Upgrade installieren soll, damit mein System den Funktionsumfang hat, als wenn ich eine Neuinstallation der neuen Version wählen würde, wo dann bestimmte Pakete standardmäßig installiert werden?
Ein anderes Beispiel wäre, wenn bei einem Versionswechsel z.B. von 10.0 auf 11.0 gravierende Änderungen in der Distribution vorgenommen werden, wie z.B. Ersetzung des Paketsystem durch ein anderes Paketsystem. Müsste ein Upgrade via Smart und Co. dort nicht zwangsweise scheitern?
Die Frage ist, ob es nicht generell besser ist, bei einer neuen Version stets eine Neuinstallation zu fahren..!?!?
Dies würde meiner Meinung nach auf auf neue KDE-Versionen zutreffen. Angenommen ich update von KDE3.5 auf später KDE4. KDE4 wird gravierende Neuerungen haben. Evtl. wird ein Update per Smart möglich sein. Aber ist mein System nach einem Neustart dann so, als wenn ich KDE komplett neu installiert hätte? Würden dann nicht evtl. einige Pakete nicht mitinstalliert werden bzw. würden sich nicht alte vorhandene Konfigurationsdateien störend auswirken? Eine neue KDE Version hat u.U. ein noch genialeres Look&Feel als eine vorher installierte, ältere Version. Auf dieses Look&Feel würde ich dann verzichten müssen, weil nach dem Update auf die neue KDE-Version eben doch noch die alten Konfigurationsdateien verwendet werden. Klar kann man bei der neuen Version alle Einstellungen manuell ändern, aber darum geht es mir nicht.
Machen also Online-Updates via Smart nicht deshalb nur Sinn bei kleinen Versionssprüngen, z.B. OpenSuse 10.0RC2 auf 10.0RC3 oder KDE 3.5.0 -> 3.5.1? Beim Übergang von OpenSuse 10.0 auf 10.1 gibt es ja schon gravierende Änderungen (Paketdatenbank, Networkmanager,..).
Es geht mir also nicht um technische Probleme beim upgraden auf eine nächst höhere Version, sondern nur um die Funktionalität bzw. neue Funktionen.
E)
Bei den diversen FTP-Servern bzw. Mirrors existiert eine teilweise unterschiedliche Verzeichnisstruktur, was die Repositories angeht.
Wie kann man die einzlenen Repository-Verzeichnisse bzw. Typen in der Verzeichnisstruktur der FTP-Server bzgl. Smart unterscheiden?
type=yast2: Dies ist eine Yast-Installationsquelle.
Kennzeichnend dafür ist das Vorhandensein einer 'directory.yast' Datei. Richtig?
type=apt-md: Dies ist eine Yum Quelle für RPM-Metadaten.
Kennzeichnend dafür ist das Vorhandensein der beiden Verzeichnisse 'repodata' und 'rpm'. Richtig?
type=apt-rpm: Dies ist ein APT-Repository.
Hier muss ein Verzeichnis 'base' sowie weitere Verzeichnisse 'RPMS.blabla' existieren. Richtig
F)
Im APT Repository für die Opensuse 10.1 gibt es ein Verzeichnis 'RPMS.base'. Was genau stellt dieses Verzeichnis in den APT-Repositories dar? Liegen in diesem Verzeichnis später mal alle Pakete, die auch auf den CDs der Final-Version vorzufinden sind? Ist dieses APT-Repository im Prinzip ein Abbild der Pakete der jeweiligen Finalversion?
Stellt dann 'RPMS.update' das APT-Repository-Äquivalent der Suse-Updates bereit, die man auch über Suse YOU einspielen kann?
G)
Angenommen ich möchte via Smart ein Ugrade von 10.0 auf die 10.1 Final durchzuführen.
In meiner Channel-Liste steht natürlich noch folgender Factory Channel:
Code:
[opensuse-sl-oss-factory_yast2]
type = yast2
name = OpenSuse Linux 10.1 - SL-OSS-Factory (YAST2)
baseurl = ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/inst-source/
Reicht es nun aus, diesen Channel zu entfernen und dann folgenden Channel hinzuzufügen?
Code:
[suse-base_apt]
type = apt-rpm
name = Suse Linux 10.1 - Base (APT)
baseurl = ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.1-i386/
components = base
Was passiert, wenn man beide Channel parallel aktiviert?
H)
Kann man unter der 10.1 OSS-Factory auch einen Channel für das APT KDE-Repository der OSS-10.0 hinzufügen oder handelt man sich Probleme ein?
Die Factory hat z.B. KDE 3.5.1.x, wahrend im KDE-Repository für 10.0-OSS KDE 3.5.2.x liegt.
Eigentlich müsste das doch keine Probleme machen, oder sind die KDE 3.5.1 Pakete der Factory-Version anders gebaut, als die Pakete der OSS-10.0 Version?
Eine Menge Fragen. Vielleicht profitieren von evtl. Antworten auch andere Leute.
Am liebsten wäre mir, wenn Ihr zu den einezlnen Punkten A) B) oder E) separat kurz antworten würdet.
Herzlichen Dank dafür.
Ansonsten komme ich mit Smart gut zurecht. Mein System läuft trotz der Probleme mit dem Networkmanager sehr gut und ich kann mein gesamtes System inkl. Kernel, KDE, etc. im laufenden Betrieb unter KDE komplett aktualisieren. Danach booten und alles ist prima. Natürlich habe ich mein Sytsem auch mal zerschossen. Aber dies stellt an sich klein Problem für mich da. Das bekomme ich meist irgendwie immer wieder ans Laufen. Smart ist toll, jedoch finde ich es grotten langsam. Damit aber kann ich gut leben. Das letzte Gesamtupdate hat doch glatt 2,3GB RPMs runtergeladen, mein gesamtes System aktualisiert und danach hat alles einwandfrei funktioniert.
LG, Kai