testing-header unter squeeze installieren

[kupe]

abend,

hätte da folgendes problem:
ich wollte mal anstatt ihn selbst zu kompilieren den aktuellen kernel aus testing unter squeeze ausprobieren, ansonsten aber auf jeden fall bei squeeze verbleiben.
dazu hab' ich eben testing zur sources.list hinzugefügt und wollte folgende pakete per synaptic installieren:

Code: Alles auswählen

linux-image-3.0.0-1-amd64
linux-headers-3.0.0-1-amd64

diese vormerkung lieferte allerdings unter anderem folgendes:

gnome wird entfernt
gnome-desktop-environment wird entfernt
libgnome2-canvas-perl wird entfernt
libgnome2-perl wird entfernt
libgtk2-perl wird entfernt
libperl5.10 wird entfernt

wobei lediglich die headers, welche ich aber für eine saubere fglrx-dkms-integration benötigen werde (so spricht zumindest mehrfach tante google und ohne eigene, zusätzliche header scheiterten zumindest alle kernel ab version 2.6.38.x am dkms-part für'n fglrx, mit der folge, daß der x-server seinen dienst fristlos quittierte), die deinstallationen auslösen würden.

die reine aktualisierung der jetzigen squeeze-headers auf die testing-version würde genauso die aufgelisteten elemente umnieten.

wieso aber wird bzw. würde hier u.a. gnome und konsorten entfernt?
würde eine kernel-installation nach einem solchen muster überhaupt funktionieren oder mache ich hier einen saftigen denkfehler?
hat jemand einen kernel inkl. headers erfolgreich auf diese art installieren können?

auf diesem gebiet hab' ich praktisch keinerlei erfahrung, deshalb bitte ich um etwas nachsicht, wenn hier das eigentliche problem allein vor'm rechner sitzen sollte...


danke sehr.

[Drache]

Hallo,

Also um einige deiner Fragen zu beantworten:

* Gemacht habe ich das noch nie. Auf meinen Rechnern läuft allerdings überall Testing.
* gnome hängt von gnome-desktop-environment ab
* gnome ist ein langweiliges Metapaket, das "gefahrlos" entfernt werden kann

Sieht man zum Bsp. so:

Code: Alles auswählen

$ aptitude show gnome
Paket: gnome                                
Zustand: nicht installiert
Version: 1:2.30+11
Priorität: optional
[schnip]
Hängt ab von: gnome-desktop-environment (= 1:2.30+11), gdm3 | gdm-themes,
               gnome-themes-extras, gnome-games (>= 1:2.30),
               libpam-gnome-keyring (>= 2.30), gstreamer0.10-plugins-ugly (>=
               0.10.14), gstreamer0.10-ffmpeg (>= 0.10.10), rhythmbox-plugins
               (>= 0.12.8) | banshee (>= 1.6), rhythmbox-plugin-cdrecorder (>=
               0.12.8) | banshee (>= 1.6), synaptic (>= 0.63),
               system-config-printer (>= 1.0.0), totem-mozilla,
               epiphany-extensions, gedit-plugins, evolution-plugins (>= 2.30),
               evolution-exchange (>= 2.30) | evolution-mapi (>= 0.30),
               evolution-webcal (>= 2.28), software-center, gnome-codec-install,
               transmission-gtk, avahi-daemon, tomboy (>= 1.2) | gnote

[schnap]
 
 Dieses Metapaket hängt von der Standard-Distribution der GNOME-Arbeitsumgebung
 ab, plus einer vollständigen Auswahl von Erweiterungen und anderen Anwendungen,
 die sich in GNOME und Debian integrieren, um die zurzeit bestmögliche Umgebung
 zur Verfügung zu stellen.

* Genauso verhält es sich mit

Code: Alles auswählen

aptitude show gnome-desktop-environment
Paket: gnome-desktop-environment            
Zustand: nicht installiert
Version: 1:2.30+11
Priorität: optional

Noch ein langweiliges Meta-Paket…


Wieso jetzt ein Kernel bestimmte Pakete deinstallieren will… ist vermutlich irgendeine Abhängigkeiten … Also etwa libgtk2-perl braucht libc6 ob die in squeeze ist – keine Ahnung…

Tendenziell würde ich empfehlen, notiere dir welche Pakete entfernt werden sollen und probiers mal aus – Kannst ja dann auch wieder zurückbauen.
Oder frag deine Paketverwaltung nach alternativen Lösungen ( ich weiß allerdings nicht ob Synaptic das kann)

Ach ja, nur nebenbei ich benutze im großen und ganzen auch einen Gnome-Desktop (die Metapakete fehlen bei mir allerdings alle, wie du ja oben sehen kannst)

[rendegast]

Beim kernel-Paket 3.0.0 wird der gcc-4.5 verwendet.
Der kernel selbst läuft zwar unter squeeze
(+ initramfs-tools + firmware-linux aus wheezy, eventuell auch udev und grub 1.99),

Beim Installieren der header jedoch bekommst Du einen Rattenschwanz an Abhängigkeiten,
der letztendlich zu wheezy führt (multiarch -> dessen libc6).
Daher die zur Entfernung aufgeführten "unabhängigen" Pakete.
Würdest Du hier bestätigen, käme wohl in einem weiteren Schritt der nahezu vollständige Austausch der Pakete.

Ich habe zwar die kernel-Headers mithilfe eines Dummy-Paketes für gcc-4.5 installieren können,
aber die Anwendung (nvidia-Installer) steigt dann beim Bau des Moduls aus, da der vorhandenen gcc-4.4 einfach nicht paßt.



Möglich wäre das Bauen eines eigenen Kernelpaketes aus den vanilla- oder debian-Quellen,
oder Du wartest auf ein backports-Paket des kernel 3.x.x und benutzt bis dahin deren 2.6.39.





-----------------------------------------------
EDIT 20110901,
Modulbau, mindest. ab nvidia 280.*, geht doch mit kernel3 debian + gcc-4.4, siehe weiter unten.

[kupe]

herzlichen dank für eure ausführlichen antworten, mal wieder einiges dazugelernt...

eins noch:

Ich habe zwar die kernel-Headers mithilfe eines Dummy-Paketes für gcc-4.5 installieren können,
aber die Anwendung (nvidia-Installer) steigt dann beim Bau des Moduls aus, da der vorhandenen gcc-4.4 einfach nicht paßt.

[noob]hmm, tut mir leid, die engültige quintessenz dieser aussage erschließt sich mir noch nicht.
soll das heißen, ich müßte mich schlau machen, welche gcc-4.x-version die gewünschte anwendung gerne hätte?
und dementsprechende headers auftreiben?[/noob]

Möglich wäre das Bauen eines eigenen Kernelpaketes aus den vanilla- oder debian-Quellen,
oder Du wartest auf ein backports-Paket des kernel 3.x.x und benutzt bis dahin deren 2.6.39.

den kernel könnte ich freilich selber basteln, aber dann bliebe ja wieder das headers-problem respektive wo bekäme ich dann die passenden headers für den eigenbau-pinguin her? wie gesagt, mit bspw. dem 39.3er ohne zusätzliches gelumse streikt der x-server...

[rendegast]

welche gcc-4.x-version die gewünschte anwendung gerne hätte?

In dem erwähnten nvidia-Installer ist es zunächst einmal ein Test,
mit welchem gcc der Ziel-kernel gebaut wurde.
Dieser kann recht einfach mit einem 'CC=gcc-4.4 nvidia-installer.run' übergangen werden.
Dann wird in speziell diesem Fall eigentlich nur eine Hülle für das vorliegende binäre Modul gestrickt,
was keine großartigen Compiler-Fähigkeiten voraussetzen sollte.
Trotzdem bricht der Modulbau ab.

In einem weiteren Testlauf habe ich das mir problematisch erscheinende Paket multiarch durch einen dummy ersetzt
und versucht, den gcc-4.5 "ohne Schnickschnack" hinzuzufügen:

Code: Alles auswählen

aptitude -s --without-recommends install gcc-4.5 -t testing

Zuerst als normaler user sah die zweite Wahl-Alternative gut aus.
Aber der simulierte Lauf unter root hat n Pakete zur De-Installation ausgewählt!
Nach einem sehr leicht passierenden Fehler haben sich auch deren Automatik-Status in 'manuell' geändert,
und ich konnte einige Zeit mit dem Wiederherstellen der Liste verbringen.
Mein Fazit: Ohne entweder den gcc-4.5 in den backports
oder alternativ einem (mit gcc-4.4 gebauten?) backports-Kernel3 geht es nicht.


Hier ist wohl eine Zäsur eingeleitet,
die eine Entscheidung des Users zum Umstieg auf wheezy nötig macht.

EDIT 20110901,
Modulbau, mindest. ab nvidia 280.*, geht doch mit kernel3 debian + gcc-4.4, siehe weiter unten.

den kernel könnte ich freilich selber basteln, aber dann bliebe ja wieder das headers-problem respektive wo bekäme ich dann die passenden headers für den eigenbau-pinguin her?

Jetzt überleg noch mal.

[kupe]

den kernel könnte ich freilich selber basteln, aber dann bliebe ja wieder das headers-problem respektive wo bekäme ich dann die passenden headers für den eigenbau-pinguin her?

Jetzt überleg noch mal.

oh mann, hast völlig recht, vergiss die frage.
die aktuelle gluthitze bekommt mir wohl nicht uneingeschränkt...

ansonsten dank' ich dir für deine ausführliche erklärung zum thema gcc, dann werd' ich mal lieber losbasteln und testing testing sein lassen, denn bei einem versionsmix soll ja nach der allgemeinen auffassung noch nie wirklich optimales herausgekommen sein...

[rendegast]

'CC=gcc-4.4 nvidia-installer.run' ....
... Trotzdem bricht der Modulbau ab. [gegen den kernel3 debian]

Das lag aber nach meinen heutigen Versuchen nicht am Bezug auf den gcc-4.5,
sondern am dabei verwendeten nvidia 270.*.

Mit dem 280.13 + gcc-4.4 funktioniert der Modulbau.
viewtopic.php?f=33&t=131298