Angenommen, ich möchte eine neuere Softwareversion als für meine aktuelle Version eines Betriebssystems verfügbar ist, was kann ich tun?
Zu berücksichtigende Fälle:
- Es gibt halboffizielle/offizielle Quellen für zusätzliche Pakete
, die für diese Version des Betriebssystems verfügbar sind. Z.B. backports.org für Debian
oder PPAs für Ubuntu. - Es sind keine neueren Versionen des Pakets für diese
Version des Betriebssystems verfügbar, aber es sind neuere Versionen für
neuere Versionen des Betriebssystems verfügbar. Dies ist der Standardfall für
Rückportierungen. - Es sind keine Paketversionen neuerer Versionen der
Software verfügbar. Verfügbare Optionen sind das Packen der neueren
Version.
Akzeptierte Antwort:
(Wenn Sie Fragen/Kommentare zu dieser Antwort haben, fügen Sie bitte einen Kommentar hinzu. Oder, wenn Sie genügend Repräsentanten haben, können Sie mich im Chat anpingen.)
Binärpakete direkt von einer neueren Version von Debian installieren – nicht die Antwort.
Angenommen, Sie führen eine Version einer Debian-basierten Distribution aus. Sie möchten eine neuere Version eines Pakets, als Ihnen zur Verfügung steht. Das erste, was jeder Anfänger versucht, ist es, das Binärpaket direkt auf Ihrer Debian-Version zu installieren. Dies kann funktionieren oder nicht, je nachdem, welche Version Sie ausführen und wie viel neuer das Paket ist. Im Allgemeinen wird dieses Verfahren nicht gut funktionieren.
Betrachten Sie zum Beispiel den Fall, in dem versucht wird, ein Binärpaket von Testing/Unstable direkt auf Stable zu installieren. Dies wird höchstwahrscheinlich nicht gut gehen, es sei denn, Testing/Unstable kommt in diesem Moment sehr nahe an Stable heran. Der Grund hat mit der Natur einer Linux-basierten Binärdistribution wie Debian zu tun. Solche Betriebssysteme hängen stark von gemeinsam genutzten Bibliotheken ab, und diese Abhängigkeiten sind oft sehr stark versionsabhängig; oft viel mehr als nötig. Debian hat derzeit keine gute Möglichkeit, Versionsabhängigkeiten „eng“ zu machen – eine Kurzform, um zu sagen, dass die Versionsabhängigkeit genau so restriktiv wie nötig ist.
Was bedeutet das für den Benutzer? Angenommen, Sie versuchen beispielsweise, slrn zu installieren von Debian Unstable zu Debian Stable. Wie würde das aussehen?
# apt-get install slrn/unstable
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '1.0.1-10' (Debian:testing [amd64]) for 'slrn'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
slrn : Depends: libc6 (>= 2.15) but 2.13-38+deb7u1 is to be installed
E: Unable to correct problems, you have held broken packages.
Trotz des von apt erzeugten Fehlers , gibt es hier keine beschädigten Pakete. Also, was ist schief gelaufen? Das Problem ist, dass die Version von libc6 dass die unstable slrn kompiliert wurde, ist anders (und hat eine höhere Versionsnummer) als die, die auf Debian Stable verfügbar ist. (libc6 ist die GNU C-Bibliothek. Die C-Bibliothek ist von zentraler Bedeutung für jedes Unix-ähnliche Betriebssystem, und die GNU-C-Bibliothek ist die Version, die Linux-basierte Betriebssysteme im Allgemeinen verwenden.)
Daher das instabile slrn erfordert eine höher nummerierte Version von libc6 als für stabil verfügbar ist. Beachten Sie, dass, weil ein Paket mit einer höheren Version der Bibliothek kompiliert wurde, nicht unbedingt eine höhere Version dieser Bibliothek erforderlich ist, aber es ist oft der Fall.
Die Syntax
apt-get install slrn/unstable
bedeutet:benutze den unstable slrn aber für alle anderen Pakete verwenden Sie nur die Versionen von stable. Genauer gesagt verwendet es Prioritätsnummern. Siehe man apt_preferences für Details.
Kann man auch machen
apt-get install -t unstable slrn
Dies funktioniert viel wahrscheinlicher, aber Sie möchten es im Allgemeinen nicht tun. Warum?
Das bedeutet:vorübergehend alle behandeln Pakete in Unstable gleichberechtigt mit den Paketen in Stable. Daher wird das instabile slrn hineingezogen ’s-Abhängigkeiten von Unstable, wenn sie eine höhere Versionsnummer haben, und das werden sie im Allgemeinen auch sein. Aus bereits erläuterten Gründen wird dies im Allgemeinen die GNU-C-Bibliothek einschließen. Nun, dieser Ansatz wird im Allgemeinen „erfolgreich“ sein, da die Abhängigkeiten per Definition erfüllt werden (unstables slrn hat Abhängigkeiten, die in Unstable erfüllt sind), aber Sie erhalten am Ende eine Mischung von Paketen, die plötzlich gezwungen sind, mit Versionen von Bibliotheken zu laufen, die sich von denen unterscheiden, für die sie gebaut wurden. Das wird wahrscheinlich nicht gut enden.
Die Antwort lautet… RÜCKWÄRTS!
Also, was ist der richtige Weg, dies zu tun? Es dient dazu, die Debian-Quellen neuerer Versionen auf Ihrem System neu zu erstellen, allgemein als „Rückportierung“ bekannt.
Betrachten Sie die folgenden Fälle:
Es gibt halboffizielle/offizielle Quellen zusätzlicher Pakete für diese Version von Debian.
Die erste Anlaufstelle ist Debian Backports, die offizielle Seite für Debian-Backports.
Für ein konkretes Beispiel:
Fügen Sie die entsprechende Backports-Zeile für Ihre Veröffentlichung hinzu und aktualisieren Sie, um die neuen Pakete zu finden, und installieren Sie dann explizit etwas von Backports (da Backports standardmäßig deaktiviert sind).
echo "deb http://ftp.debian.org/debian stretch-backports main" | sudo tee /etc/apt/sources.list.d/stretch-backports.list
sudo apt-get update
sudo apt-get install -t stretch-backports git
Dadurch erhalten Sie die neueste stabile Version von Git, die nützliche neuere Funktionen als die in Stretch enthaltene stabile enthält (z. B. „include“, mit dem Sie mehrere Konfigurationsdateien kombinieren oder Ihren Benutzernamen für ~/work/projects/ vs. Projekte/).
Ein weiterer Ort, den Sie sich ansehen sollten, sind die verschiedenen PPAs von Ubuntu-Maintainern. Sie können nach „Paketname PPA“ suchen.
Es sind keine neueren Versionen des Pakets für diese Version des Betriebssystems verfügbar, aber es sind neuere Versionen für neuere Versionen/Releases des Betriebssystems verfügbar. Dies ist der Standardfall für die Rückportierung.
Backporting bedeutet, dass Sie die Debian-Quellen von einer neueren Version von Debian auf der Version, die Sie ausführen, neu erstellen. Dieses Verfahren kann je nach Paket einfach oder aufwendig und schwierig sein. Hier ist eine Übersicht, wie das geht.
Ein kurzes Backporting-Tutorial für Anfänger
Aus Gründen der Konkretheit gehe ich davon aus, dass Sie den aktuellen Debian-Stall ausführen, derzeit keuchend. Ich verwende das Paket slrn als Beispiel.
Beachten Sie zunächst, dass sich alle Debian-Paketdateien im debian/ befinden Unterverzeichnis des Quellverzeichnisses.
Prüfen Sie im ersten Schritt, ob eine neuere Version verfügbar ist. Sie können dies mit apt-cache policy tun .
apt-cache policy slrn
slrn:
Installed: 1.0.0~pre18-1.3
Candidate: 1.0.0~pre18-1.3
Version table:
1.0.1-10 0
50 http://debian.lcs.mit.edu/debian/ testing/main amd64 Packages
50 http://debian.lcs.mit.edu/debian/ unstable/main amd64 Packages
*** 1.0.0~pre18-1.3 0
500 http://debian.lcs.mit.edu/debian/ wheezy/main amd64 Packages
100 /var/lib/dpkg/status
1.0.0~pre18-1.1 0
500 http://debian.lcs.mit.edu/debian/ squeeze/main amd64 Packages
Wir möchten 1.0.1-10 zurückportieren .
SCHRITT 1:
NB:Stellen Sie sicher, dass die Datei deb-src Zeilen für die Quellversion, die Sie herunterladen möchten, erscheint in Ihrer /etc/apt/sources.list . Zum Beispiel, wenn Sie die instabile Version von slrn herunterladen möchten , benötigen Sie den deb-src Zeile für instabil, oder es funktioniert nicht. Beachten Sie, dass Sie das entsprechende deb nicht benötigen Zeilen zum Herunterladen der Quellen, obwohl apt-cache policy verwendet diese Informationen, wenn Sie also nicht über das entsprechende deb verfügen Zeilen, dann apt-cache policy zeigt Ihnen nicht die relevante(n) Version(en) an. Wenn Sie die Datei deb haben vergessen Sie nicht, die neueren Versionen mit einem Eintrag in /etc/apt/preferences anzuheften oder ähnliches. Ein Eintrag in /etc/apt/preferences so (für unstable) funktioniert zum Beispiel.
Package: *
Pin: release a=unstable
Pin-Priority: 50
Wenn Sie Zeilen in /etc/apt/sources.list hinzufügen , vergessen Sie nicht, apt-get update auszuführen danach.
Laden Sie die Quellen für slrn herunter . Ein guter Ort ist /usr/local/src/slrn .
apt-get source slrn=1.0.1-10
SCHRITT 2:
Ändern Sie die Versionsnummer leicht, um Ihren Backport von der Upstream-Version zu unterscheiden. Führen Sie dch --bpo aus , wodurch automatisch ein Eintrag zum debian/changelog hinzugefügt wird Datei mit einer entsprechenden Versionsnummer, zum Beispiel
slrn (1.0.1-10~bpo10+1) UNRELEASED; urgency=low
* Backport to buster.
-- User <[email protected]> Sun, 02 Feb 2014 23:54:13 +0530
SCHRITT 3:
Versuchen Sie, die Quellen zu erstellen. Wenn die für den Build erforderlichen Pakete nicht verfügbar sind, schlägt der Versuch fehl. Wechseln Sie in das Quellverzeichnis. Verwenden Sie debuild aus den devtools Paket.
cd slrn-1.0.1/
debuild -uc -us
Wenn die Build-Abhängigkeiten erfüllt sind, werden die Quellen einige Debs auf der Ebene über dem Quellverzeichnis erstellen und produzieren; in diesem Fall /usr/local/src/slrn .
SCHRITT 4:
Angenommen, die Build-Abhängigkeiten sind nicht erfüllt. Dann müssen Sie versuchen, die Build-Abhängigkeiten zu installieren. Dies kann funktionieren oder nicht, da die Abhängigkeiten möglicherweise nicht für Ihre Version verfügbar sind oder, falls verfügbar, möglicherweise nicht in der richtigen Version verfügbar sind.
NB:Es ist leider nicht ungewöhnlich, dass Debian-Pakete Versionen von Build-Abhängigkeiten erfordern, die höher als nötig sind. Es gibt in Debian keine automatisierte Möglichkeit, dies zu überprüfen, und oft ist es Paketbetreuern egal, solange es auf der entsprechenden Version/Veröffentlichung funktioniert. Nehmen Sie daher eine skeptische Haltung gegenüber Abhängigkeitsversionen ein und verwenden Sie Ihren gesunden Menschenverstand. Zum Beispiel werden weit verbreitete Pakete wie Python und die GNU-Tools nicht von sehr spezifischen Versionen ihrer Abhängigkeiten abhängen, unabhängig davon, was der Debian-Paketierer auflistet.
Siehe auch:Debian – Wie können wir vorhersagen, wann die nächste Debian-Veröffentlichung erscheinen wird?In jedem Fall können Sie versuchen, sie zu installieren
apt-get build-dep slrn=1.0.1-10
Wenn dies erfolgreich ist, versuchen Sie erneut, das Paket zu erstellen (SCHRITT 2). Wenn dies fehlschlägt, ist weitere Arbeit erforderlich. Beachten Sie, dass debuild betrachtet die Build-Abhängigkeiten in debian/control Datei, und Sie können diese bei Bedarf ändern. Also lass uns jetzt darüber reden. Hier sind die Build-Abhängigkeiten für slrn.
Build-Depends: debhelper (>=9), libslang2-dev, libuu-dev,
exim4 | mail-transport-agent, libgnutls-openssl-dev, po-debconf, autoconf,
libcanlock2-dev, autotools-dev, dpkg-dev (>= 1.16.0), chrpath, dh-autoreconf, inn2-inews
Eine Alternative zur Verwendung von apt-get build-dep ist, diese manuell zu installieren, indem Sie
apt-get install debhelper libslang2-dev ...
Wenn Sie beginnen, diese Werte in der Steuerdatei zu ändern, sollten Sie auf eine manuelle Installation umstellen, da dann apt-get build-dep wird nicht mehr das Richtige tun.
Es sind keine Paketversionen neuerer Versionen der Software verfügbar. Verfügbare Optionen sind die neuere Version zu packen.
In vielen Fällen kann man das Paket aus früheren Versionen der Software in Verbindung mit neueren Quellen wiederverwenden. Dieser Ansatz kann zu Problemen führen, insbesondere Patches, die auf frühere Versionen der Software angewendet wurden, gelten hier möglicherweise nicht, sodass Sie sie möglicherweise mit den Quellen erneut synchronisieren müssen. Das Quellformat 3.0 (quilt), das jetzt zum Standard wird, verwendet quilt, und Patches befinden sich in debian/patches Verzeichnis.
Eine detaillierte Erörterung dieser Probleme ist jedoch für diesen Beitrag nicht vorgesehen.