A
Anonymous
Gast
Vorgeschichte:
Dieses Problem tritt seit openSUSE 11.0 RC1 reproduzierbar auf, es ist nicht von der Kernelversion abhängig, da eine 10.3 mit "custom-Kernel nach SuSE Art" (also auch über Build Service erstellt, Version 2.6.25.6) dieses Verhalten bei identischem src.rpm nicht aufzeigt.
Aufgefallen ist der ganze Schlamassel hier:
http://www.pc-forum24.de/beta-forum/9635-suse11rc1-ath5k.html
Symptome:
Nach einem fehlerfreien Rebuild eines des compat-wireless-src.rpm kann das entsprechende kmp-Paket nicht installiert werden:
Das entsprechende Symbol ist nicht in kernel-syms (symvers/symsets&co) enthalten, jedoch ist dies unter 10.3, wo dieses Problem nicht auftritt, genau so.
Ein Vergleich der Ausgaben von
zeigt folgenden Unterschied:
openSUSE 11.0:
openSUSE 10.3
Beide Pakete liefern als "Provides" (siehe verlinkten Thread, das zu posten habe ich mir erspart, das ist ja auch genau so, wie es sein soll) das Symbol "__ieee80211_get_channel", aber das Paket für 11.0 setzt dieses Symbol auch (IMHO fälschlicherweise) als "Requires" ein, was zum klassischen "Henne <=> Ei"-Problem führt.
Interessanterweise funktionieren die Treiber aus dem Paket aber, wenn man es mit der entsprechenden "bösen" Option "mit Gewalt" installiert problemlos, aber das ist natürlich keine Option.
Es stellen sich für mich nun folgende Fragen:
- Welcher Mechanismus sorgt für die Erkennung der Requires, oder genauer wo kann ich ansetzten und die Ursache dieses Fehlers zu finden? (daß es sich um den Tag "Autoreqprov: on" handelt und dafür wohl auch das Script "/usr/lib/rpm/find-requires" zuständig sind, ist für mich das Wahrscheinlichste, aber dazu sind meine Kenntnisse einfach noch zu bescheiden).
- Wie kann ich notfalls beeinflussen, welche Requires _nicht_ gesetzt werden, der umgekehrte Fall ist ja entsprechend simpel (entweder direkt im SPEC oder über die preamble). Somit wäre zumindest ein "Würgaround" möglich, denn in diesem "Zustand" möchte ich die Pakete nicht veröffentlichen.
Ich habe in der Zwischenzeit etwa 20 weitere src.rpms, die am Ende kmp-Pakete ausspucken, unter 11.0 mittels rpmbuild --rebuild erzeugt und ein analoges Problem trat nirgends auf.
Ach ja, es kann auch nicht an meiner Maschine/Build-Umgebung und meiner "Nichtverwendung" von lbuild o.ä. liegen, da dieses Problem reproduzierbar zumindest auf 3 unterschiedlichen Maschinen und auch bei den Paketen aus dem openSUSE Build Service (schmolles Repository) auftritt.
Ich bin für jede Anregung dankbar.
Greetz,
RM
Dieses Problem tritt seit openSUSE 11.0 RC1 reproduzierbar auf, es ist nicht von der Kernelversion abhängig, da eine 10.3 mit "custom-Kernel nach SuSE Art" (also auch über Build Service erstellt, Version 2.6.25.6) dieses Verhalten bei identischem src.rpm nicht aufzeigt.
Aufgefallen ist der ganze Schlamassel hier:
http://www.pc-forum24.de/beta-forum/9635-suse11rc1-ath5k.html
Symptome:
Nach einem fehlerfreien Rebuild eines des compat-wireless-src.rpm kann das entsprechende kmp-Paket nicht installiert werden:
Code:
# rpm -i compat-wireless-kmp-default-20080615_2.6.25.5_1.1-1.1.x86_64.rpm
#error: Failed dependencies:
ksym(default:__ieee80211_get_channel) = a62b27f7 is needed by compat-wireless-kmp-default-20080615_2.6.25.5_1.1-1.1.x86_64
Das entsprechende Symbol ist nicht in kernel-syms (symvers/symsets&co) enthalten, jedoch ist dies unter 10.3, wo dieses Problem nicht auftritt, genau so.
Ein Vergleich der Ausgaben von
Code:
rpm -q --requires compat-wireless-kmp-default
zeigt folgenden Unterschied:
openSUSE 11.0:
Code:
nescaya:/home/cal # rpm -q --requires compat-wireless-kmp-default
rpmlib(VersionedDependencies) <= 3.0.3-1
kernel-default
grep
coreutils
/bin/sh
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
kernel(default:vmlinux) = f30985aa0d58b1bd
kernel(default:drivers_pcmcia) = d6e12e68b28e8185
kernel(default:drivers_leds) = 9c7be1407c475206
kernel(default:drivers_usb_core) = 5f7ab15d128f85da
kernel(default:lib) = 3d902850a781f266
kernel(default:drivers_input) = 6838d12e58f8c652
kernel(default:drivers_net_usb) = 8c4b5210ecad206d
kernel(default:drivers_mmc_core) = a4e7202433369dc1
kernel(default:net_rfkill) = cbce6028156b37d9
kernel(default:drivers_base) = 7522f9b3902583db
ksym(default:__ieee80211_get_channel) = a62b27f7
rpmlib(PayloadIsLzma) <= 4.4.2-1
openSUSE 10.3
Code:
rpm -q --requires compat-wireless-kmp-default
rpmlib(VersionedDependencies) <= 3.0.3-1
kernel-default
/bin/sh
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
kernel(vmlinux) = 7478eee6b17e0a6e
kernel(drivers_base) = 764d234a57393d3a
kernel(drivers_net_usb) = b32878b4de53e5a1
kernel(drivers_usb_core) = 4c72c467f0d75340
kernel(drivers_pcmcia) = 04961ed03875aff1
kernel(drivers_leds) = 41e22d9abdc48913
kernel(lib) = 086af86b98115d0b
rpmlib(PayloadIsBzip2) <= 3.0.5-1
Beide Pakete liefern als "Provides" (siehe verlinkten Thread, das zu posten habe ich mir erspart, das ist ja auch genau so, wie es sein soll) das Symbol "__ieee80211_get_channel", aber das Paket für 11.0 setzt dieses Symbol auch (IMHO fälschlicherweise) als "Requires" ein, was zum klassischen "Henne <=> Ei"-Problem führt.
Interessanterweise funktionieren die Treiber aus dem Paket aber, wenn man es mit der entsprechenden "bösen" Option "mit Gewalt" installiert problemlos, aber das ist natürlich keine Option.
Es stellen sich für mich nun folgende Fragen:
- Welcher Mechanismus sorgt für die Erkennung der Requires, oder genauer wo kann ich ansetzten und die Ursache dieses Fehlers zu finden? (daß es sich um den Tag "Autoreqprov: on" handelt und dafür wohl auch das Script "/usr/lib/rpm/find-requires" zuständig sind, ist für mich das Wahrscheinlichste, aber dazu sind meine Kenntnisse einfach noch zu bescheiden).
- Wie kann ich notfalls beeinflussen, welche Requires _nicht_ gesetzt werden, der umgekehrte Fall ist ja entsprechend simpel (entweder direkt im SPEC oder über die preamble). Somit wäre zumindest ein "Würgaround" möglich, denn in diesem "Zustand" möchte ich die Pakete nicht veröffentlichen.
Ich habe in der Zwischenzeit etwa 20 weitere src.rpms, die am Ende kmp-Pakete ausspucken, unter 11.0 mittels rpmbuild --rebuild erzeugt und ein analoges Problem trat nirgends auf.
Ach ja, es kann auch nicht an meiner Maschine/Build-Umgebung und meiner "Nichtverwendung" von lbuild o.ä. liegen, da dieses Problem reproduzierbar zumindest auf 3 unterschiedlichen Maschinen und auch bei den Paketen aus dem openSUSE Build Service (schmolles Repository) auftritt.
Ich bin für jede Anregung dankbar.
Greetz,
RM