"could not open RPM database" und .rpmmacros

[bitmuncher]

Ich hab hier einen Benutzer, der eine eigene .rpmmacros-Datei in seinem $HOME liegen hat. Diese hat folgenden Inhalt:

%_var                   /home/user/.apt/.apt/var
%_cache_dbpath          /home/user/.apt/.apt/var/spool/up2date/cache
%_repackage_dir         /home/user/.apt/.apt/var/spool/repackage
%_localstatedir         /home/user/.apt/.apt/var
%_dbpath                /home/user/.apt/var/lib/rpm
%_rpmlock_path          %{_dbpath}/__db.000
%_topdir         /home/user/.apt/rpm
%_specdir        /home/user/.apt/rpm/SPECS
%_tmppath        /home/user/.apt/tmp
%_tmpdir         /home/user/.apt/tmp
%_rpm_root      /home/user/.apt/rpm/
%_rpmdir        %{_topdir}/RPMS/ 
%_binary_payload w9.gzdio

Das ganze wird durch ein apt-get genutzt, das speziell für den User eingebaut ist und auf apt4rpm aufsetzt. Dummerweise bekomme ich aber bei einem 'apt-get update' immer die Meldung "E: could not open RPM database", weil er die offenbar immer noch in /var/lib/rpm sucht.

error: cannot open Packages database in /var/lib/rpm
E: could not open RPM database

Fehlt ihr irgendeine Direktive in der .rpmmacros oder wo kann sonst noch der Fehler liegen? Als Distro liegt OpenSuSE 11.2 zugrunde.

Edit: Ein Anzeigen der Config zeigt auch keinen Hinweis darauf, dass /var/lib/rpm noch genutzt wird.

rpm --macros ~/.rpmmacros --showrc
ARCHITECTURE AND OS:
build arch            : x86_64
compatible build archs: x86_64 noarch
build os              : Linux
compatible build os's : Linux
install arch          : x86_64
install os            : Linux
compatible archs      : x86_64 amd64 em64t athlon noarch i686 i586 i486 i386 fat
compatible os's       : Linux

RPMRC VALUES:
optflags              : -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables

Features supported by rpmlib:
    rpmlib(BuiltinLuaScripts) = 4.2.2-1
    rpmlib(CompressedFileNames) = 3.0.4-1
    rpmlib(ConcurrentAccess) = 4.1-1
    rpmlib(ExplicitPackageProvide) = 4.0-1
    rpmlib(FileDigests) = 4.6.0-1
    rpmlib(HeaderLoadSortsTags) = 4.0.1-1
    rpmlib(PartialHardlinkSets) = 4.0.4-1
    rpmlib(PayloadFilesHavePrefix) = 4.0-1
    rpmlib(PayloadIsBzip2) = 3.0.5-1
    rpmlib(PayloadIsLzma) = 4.4.2-1
    rpmlib(PayloadIsXz) = 5.2-1
    rpmlib(ScriptletInterpreterArgs) = 4.0.3-1
    rpmlib(VersionedDependencies) = 3.0.3-1

========================
-14: _binary_payload    w9.gzdio
-14: _cache_dbpath      /home/user/.apt/.apt/var/spool/up2date/cache
-14: _dbpath    /home/user/.apt/var/lib/rpm
-14: _localstatedir     /home/user/.apt/.apt/var
-14: _repackage_dir     /home/user/.apt/.apt/var/spool/repackage
-14: _rpm_root  /home/user/.apt/rpm/
-14: _rpmdir    %{_topdir}/RPMS/
-14: _rpmlock_path      %{_dbpath}/__db.000
-14: _specdir   /home/user/.apt/rpm/SPECS
-11: _target    x86_64-linux
-11= _target_cpu        x86_64
-11= _target_os linux
-14: _tmpdir    /home/user/.apt/tmp
-14: _tmppath   /home/user/.apt/tmp
-14: _topdir    /home/user/.apt/rpm
-14: _var       /home/user/.apt/.apt/var
-11: optflags   -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables
======================== active 17 empty 0

 

[mime]

Ich hab hier einen Benutzer, der eine eigene .rpmmacros-Datei in seinem $HOME liegen hat.

[...]

error: cannot open Packages database in /var/lib/rpm
E: could not open RPM database

Fehlt ihr irgendeine Direktive in der .rpmmacros oder wo kann sonst noch der Fehler liegen? Als Distro liegt OpenSuSE 11.2 zugrunde.

Soweit ich das beurteilen kann sehen die Macros gut aus. An denen liegt es wohl nicht.
Unter welchem User führst du das "apt-get update" aus? Unter dem User, in dessen $home das ".rpmmacros" liegt?
Ich musste meinem User nämlich erst einmal Schreibrechte auf "/var/lib/apt/lists/lock" geben damit das funktioniert.
Wenn du das nicht unter diesem User ausführst, dann ".rpmmacros" nach /etc/rpm/macros kopieren und nochmal versuchen.

mime@openvas-qa1:~> strace -e trace=open apt-get update
[...]
open("/etc/rpm/macros.gconf2", O_RDONLY|O_LARGEFILE) = 5
open("/etc/rpm/macros.jpackage", O_RDONLY|O_LARGEFILE) = 5
open("/etc/rpm/macros.kde4", O_RDONLY|O_LARGEFILE) = 5
open("/etc/rpm/macros.kernel-source", O_RDONLY|O_LARGEFILE) = 5
open("/etc/rpm/macros.mkinitrd", O_RDONLY|O_LARGEFILE) = 5
open("/etc/rpm/macros.python", O_RDONLY|O_LARGEFILE) = 5
open("/etc/rpm/macros.ruby", O_RDONLY|O_LARGEFILE) = 5
open("/etc/rpm/macros.tcl", O_RDONLY|O_LARGEFILE) = 5
open("/etc/rpm/macros", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/etc/rpm/i586-linux/macros", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/mime/.rpmmacros", O_RDONLY|O_LARGEFILE) = 5
[...]
open("/home/mime/.apt/.apt/var/lib/rpm/DB_CONFIG", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/mime/.apt/.apt/var/lib/rpm/Packages", O_RDONLY|O_LARGEFILE) = 5
open("/home/mime/.apt/.apt/var/lib/rpm/Packages", O_RDONLY|O_LARGEFILE) = 5

Funktioniert..."/home/mime/.rpmmacros" ist eine Kopie "deiner" .rpmmacros mit angepassten Pfaden.

Im zweifel das "apt-get update" mal mit strace (wie oben zu sehen) laufen lassen. Vielleicht siehst du dann woran es bei dir liegt.

Getestet mit OpenSuSE 11.1

HTH

Micha

 

[bitmuncher]

Das apt-get wird mit dem User ausgeführt, dem auch die .rpmmacros gehört. Diese liegt in seinem Home. Da das Apt auch User-spezifisch ist, das in $HOME/.apt liegt, sollte eine Anpassung von globalen Pfaden nicht notwendig sein. Damit das korrekte Apt verwendet wird hat der User folgende Daten in seiner .bashrc

# APT Config, libs and paths
APT_CONFIG=$HOME/.apt/etc/apt/apt.conf.d/apt.conf
#PATH=$PATH:$HOME/.apt/bin
PATH=$HOME/.apt/bin:$PATH
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/.apt/lib
export PATH LD_LIBRARY_PATH APT_CONFIG

alias apt-get="apt-get -c $APT_CONFIG"
alias apt-cache="apt-cache -c $APT_CONFIG"
alias apt-config="apt-config -c $APT_CONFIG"

Edit: Wenn ich es mit strace laufen lasse (strace -e trace=open /home/cgt/.apt/bin/apt-get update), behauptet apt-get dass es /usr/lib64/apt/methods/ssh nicht finden kann. Dies ist aber nicht der Fall, wenn ich das strace weglasse, weswegen ich da eher strace als Fehlerursache sehe.

 

[mime]

Edit: Wenn ich es mit strace laufen lasse (strace -e trace=open /home/cgt/.apt/bin/apt-get update), behauptet apt-get dass es /usr/lib64/apt/methods/ssh nicht finden kann. Dies ist aber nicht der Fall, wenn ich das strace weglasse, weswegen ich da eher strace als Fehlerursache sehe.

Nein. strace hat ja keinen Einfluss darauf, was geladen werden soll. Wird denn die "~/.rpmmacros" überhaupt gelesen? Solltest du ja im strace sehen...

Micha

 

[bitmuncher]

Ich ging auch davon aus, dass strace keinen Einfluss auf die Runtime hat. Das scheint aber nicht zu stimmen, denn apt-get ohne strace findet seine SSH-Module und mit strace findet es diese nicht.

Komischerweise wird laut strace gar keine rpmmacros-Datei ausgewertet, was auch nicht stimmen kann, da wenigstens die globale rpmmacros-Datei ausgewertet werden muss, da rpm sonst nicht weiss wo es seine RPM-Datenbank suchen soll. Evtl. liegt es aber auch daran, dass das SSH-Transport-Modul nicht gefunden wird.

 

[mime]

Ich ging auch davon aus, dass strace keinen Einfluss auf die Runtime hat. Das scheint aber nicht zu stimmen, denn apt-get ohne strace findet seine SSH-Module und mit strace findet es diese nicht.

Woher weisst du denn, dass apt-get das das ssh-modul findet? Gibt es die bei dir überhaupt? Bei mir gibt es die (/usr/lib/apt/methods/ssh). Ich sehe im strace bei mir allerdings nicht, dass versucht wird diese zu lesen.

Komischerweise wird laut strace gar keine rpmmacros-Datei ausgewertet, was auch nicht stimmen kann,

Aber genau das erklärt doch, dass es nicht funktioniert. strace zeigt dir keinen Unsinn an. Du kannst einem strace in der Regel vertrauen. Wenn strace sagt das diese Datei nicht gelesen wird, dann wird sie nicht gelesen.

Evtl. liegt es aber auch daran, dass das SSH-Transport-Modul nicht gefunden wird.

Ich glaube eher nicht...

Nimm mal den Schalter "-f" bei strace dazu. Wenn du magst, kannst du den Output von

strace -o /tmp/apt.trace -f apt-get update

mal irgendwo (z.B. pastebin.com) hinlegen. Also den Inhalt der Datei /tmp/apt.trace...

Micha

 

[bitmuncher]

Ich weiss es daher:

user@meinserver:~> apt-get update
Get:1 ssh://user@meinserver.de release repomd.xml [1950B]
Fetched 1950B in 0s (2132B/s)          
[b]Hit ssh://user@meinserver.de release/ primary.xml
Hit ssh://user@meinserver.de release/ filelists.xml[/b]

Die Dateien könnte er ohne SSH-Transportmodul gar nicht abrufen. Das wiederum weiss ich aus Erfahrung, denn das Problem hatte ich vorhin bereits, bis ich das SSH-Modul eingebaut hatte.

Damit kann die Meldung, die in Verbindung mit strace kommt nicht korrekt sein:

E: The method driver /usr/lib64/apt/methods/ssh could not be found.

strace zeigt also offenbar doch Unsinn. Naja, nicht wirklich, wie ich gerade festgestellt habe. Der "Trick" ist, dass der Aufruf so aussehen muss: ' strace -e trace=open apt-get -c .apt/etc/apt/apt.conf.d/apt.conf update', da es sich ja um ein User-spezifisches apt handelt und die .bashrc bzw. die Aliases in dieser von strace ignoriert werden.

Dass keine Macros-Datei ausgewertet wird, zeigt aber auch der folgende Output:

user@meinserver:~> strace -o strace.out -f apt-get -c .apt/etc/apt/apt.conf.d/apt.conf update
Get:1 ssh://user@meinserver.de release repomd.xml [1950B]
Fetched 1950B in 1s (1792B/s)          
Hit ssh://user@meinserver.de release/ primary.xml
Hit ssh://user@meinserver.de release/ filelists.xml
error: cannot open Packages database in /var/lib/rpm
E: could not open RPM database
user@meinserver:~> grep macro strace.out 
user@meinserver:~>

Und es kann einfach nicht sein, dass gar keine rpmmacros-Datei ausgewertet wird, denn sonst wüsste apt-get nichts von dem Pfad /var/lib/rpm. Dieser steht nur in der globalen macros-Datei unter /usr/lib/rpm/macros als %_dbpath. Diese wird aber laut strace auch nicht ausgewertet und das ist nunmal nicht möglich. Die wird von rpm immer ausgewertet, selbst wenn rpm nur die Hilfe-Seite auswirft. Siehe z.B. hier:

user@meinserver:/usr/lib/rpm> strace -e trace=open rpm 2>&1 | grep macros
open("/usr/lib/rpm/macros", O_RDONLY) = 3

Offensichtlich nutzt strace beim Aufruf von apt-get also eine andere Umgebung, was man z.B. auch daran merkt, dass in .bashrc gesetzte Umgebungsvariablen und Aliases von strace nicht ausgewertet werden und diese sind für ein User-Apt nunmal essentiell.

Kurzum: Ich glaube nicht, dass strace mir grossartig weiter hilft solange es behauptet, dass keine rpmmacros-Datei ausgewertet wird. Das kann jedenfalls nicht stimmen, sonst wäre der Pfad zur RPM-DB nicht ermittelbar.

Seltsam ist das alles irgendwie...

 

[mime]

Der "Trick" ist, dass der Aufruf so aussehen muss: ' strace -e trace=open apt-get -c .apt/etc/apt/apt.conf.d/apt.conf update', da es sich ja um ein User-spezifisches apt handelt und die .bashrc bzw. die Aliases in dieser von strace ignoriert werden.

mime@openvas-qa1:~> strace -f apt-get update 
18592 execve("/home/mime/.apt/bin/apt-get", ["apt-get", "update"], [/* 58 vars */]) = 0
[...]
18592 stat64("/home/mime/.apt/etc/apt/apt.conf.d/apt.conf", {st_mode=S_IFREG|0644, st_size=390, ...}) = 0

Wie du siehst, täuscht du dich. Sind deine aliase und dein Umgebungsvariablen überhaupt da? Hast du mal nachgesehen?

Und es kann einfach nicht sein, dass gar keine rpmmacros-Datei ausgewertet wird, denn sonst wüsste apt-get nichts von dem Pfad /var/lib/rpm.

openvas-qa1:~ # strings /usr/lib/librpm-4.4.so | grep /var
/var
%{?_tmppath:%{_tmppath}}%{!?_tmppath:/var/tmp}
/var
/var/tmp
/var/lib/rpm

Kurzum: Ich glaube nicht, dass strace mir grossartig weiter hilft solange es behauptet, dass keine rpmmacros-Datei ausgewertet wird.

Ich wette strace hat recht.

Micha

 

[bitmuncher]

Wie du siehst, täuscht du dich. Sind deine aliase und dein Umgebungsvariablen überhaupt da? Hast du mal nachgesehen?

Er würde das SSH-Modul ja wohl kaum ohne strace finden, wenn das Alias nicht da wäre. Aber damit du's glaubst...

user@meinserver:~> alias | grep apt
alias apt-cache='apt-cache -c /home/user/.apt/etc/apt/apt.conf.d/apt.conf'
alias apt-config='apt-config -c /home/user/.apt/etc/apt/apt.conf.d/apt.conf'
alias apt-get='apt-get -c /home/user/.apt/etc/apt/apt.conf.d/apt.conf'

Ja, die Aliases sind da.

openvas-qa1:~ # strings /usr/lib/librpm-4.4.so | grep /var
/var
%{?_tmppath:%{_tmppath}}%{!?_tmppath:/var/tmp}
/var
/var/tmp
/var/lib/rpm

Guter Hinweis. Die librpm liegt für das Apt auch an einem anderen Ort. Ggf. kommt strace deswegen damit nicht klar. SuSE 11.2 liefert nämlich keine librpm-4.4 mehr mit, weswegen diese unter /home/user/.apt/lib installiert ist. Damit sie gefunden wird, ist dieser Ordner auch in $LD_LIBRARY_PATH definiert. Bevor das der Fall war, funktioniert das apt-get gar nicht, da es sich ja um apt-rpm handelt und beim Aufruf von apt-get dann schon rumgemeckert wurde, dass librpm-4.4.so nicht gefunden werden konnte.

Ich wette strace hat recht.

Ich wette nicht. Das System ist evtl. etwas zu eigen, als dass strace damit noch zurecht kommt. Da es die aliases aus der .bashrc nicht auswertet, wertet es ggf. auch die dort gesetzten Umgebungsvariablen nicht aus. Das ist zumindest meine Vermutung und ohne $LD_LIBRARY_PATH nutzt es schlichtweg die falsche librpm, die nicht mit dem installierten apt-rpm kompatibel ist. Übrigens funktioniert das gleiche Setup auf einem OpenSuSE 11.1 und darunter problemlos. Es also mit einem solchen zu vergleichen ist unsinnig. Ich weiss, dass es dort geht. Auf 11.2 tut's das aber nunmal nicht mehr. Da aber der Support für 11.1 demnächst ausläuft, kann ich für das Projekt kein 11.1 mehr einsetzen. Schon 11.2 ist eigentlich nur eine Notlösung, bis wir eine Alternative zu apt-rpm entwickelt haben. Das tut ab 11.3 nämlich unter keinen Umständen mehr, da sich librpm-4.4 dort nicht mehr so einfach integrieren lässt.

 

[mime]

Das System ist evtl. etwas zu eigen, als dass strace damit noch zurecht kommt.

mime@linux-ivxr:~> cat .rpmmacros 
%_hackerboard
%_var                   /home/mime/.apt/.apt/var
[...]

mime@linux-ivxr:~> ls -l .apt/lib/librpm*
-rwxr-xr-x 1 mime users  407204  5. Nov 23:05 .apt/lib/librpm-4.4.so
-rwxr-xr-x 1 mime users 1073688  5. Nov 23:02 .apt/lib/librpmdb-4.4.so
-rwxr-xr-x 1 mime users  776752  5. Nov 23:02 .apt/lib/librpmio-4.4.s

mime@linux-ivxr:~> strace -o /tmp/ibrpm-4.4.trace -e trace=open apt-get update
[...]
error: cannot open Packages database in /var/lib/rpm
E: konnte RPM-Datenbank nicht öffnen
mime@linux-ivxr:~> grep macro /tmp/ibrpm-4.4.trace
mime@linux-ivxr:~>

Die .rpmmacros wird nicht gelesen.

mime@linux-ivxr:~> ls -l .apt/lib/librpm*
lrwxrwxrwx 1 mime users      20  5. Nov 23:10 .apt/lib/librpm-4.4.so -> /usr/lib/librpm.so.0
-rwxr-xr-x 1 mime users 1073688  5. Nov 23:02 .apt/lib/librpmdb-4.4.so
-rwxr-xr-x 1 mime users  776752  5. Nov 23:02 .apt/lib/librpmio-4.4.so

mime@linux-ivxr:~> strace -o /tmp/ibrpm-so.0.trace -e trace=open apt-get update
error: Macro %_hackerboard has empty body
*** glibc detected *** apt-get: realloc(): invalid pointer: 0x08087d64 ***

Gut, dass konnte man jetzt irgendwie erwarten
Aber wie du siehst...

mime@linux-ivxr:~> grep macro /tmp/ibrpm-so.0.trace
open("/usr/lib/rpm/macros", O_RDONLY|O_LARGEFILE) = 4
open("/usr/lib/rpm/platform/pentium4-linux/macros", O_RDONLY|O_LARGEFILE) = 4
open("/usr/lib/rpm/suse/macros", O_RDONLY|O_LARGEFILE) = 4
open("/etc/rpm/macros.gconf2", O_RDONLY|O_LARGEFILE) = 4
open("/etc/rpm/macros.jpackage", O_RDONLY|O_LARGEFILE) = 4
open("/etc/rpm/macros.kde4", O_RDONLY|O_LARGEFILE) = 4
open("/etc/rpm/macros.mkinitrd", O_RDONLY|O_LARGEFILE) = 4
open("/etc/rpm/macros.perl", O_RDONLY|O_LARGEFILE) = 4
open("/etc/rpm/macros.python", O_RDONLY|O_LARGEFILE) = 4
open("/etc/rpm/macros.tcl", O_RDONLY|O_LARGEFILE) = 4
open("/etc/rpm/macros.update-desktop-files", O_RDONLY|O_LARGEFILE) = 4
open("/etc/rpm/macros", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/etc/rpm/pentium4-linux/macros", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/home/mime/.rpmmacros", O_RDONLY|O_LARGEFILE) = 4

Die Fehlermeldung "error: Macro %_hackerboard has empty body" hatte es ja schon gezeigt. Hier wird die .rpmmacros gelesen.

Also strace hat recht. Mit der librpm-4.4.so wird unter einem SuSE 11.2 die ~/.rpmmacros ignoriert. Jetzt stellt sich nur noch die Frage nach dem warum.
Mache mal ein 'strings librpm-4.4.so | grep macro'' und vergleiche das mit "strings /usr/lib/librpm.so.0 | grep macro". Da scheint sich was geändert zu haben.

Du hast übrigens recht, aliase werden tatsächlich ignoriert.

Micha

 

[bitmuncher]

Danke. Das ist schonmal ein Ansatz. Ich werde mich damit am Montag weiter auseinandersetzen. Jetzt ist erstmal Feierabend und im TV läuft Jarhead.

Edit: Ich hab übrigens einen Verdacht... ich denke, dass das von OpenSuSE 11.2 mitgelieferte RPM nicht mehr mit librpm-4.4 zusammenarbeitet, da sich ja die Struktur der librpm komplett geändert hat. Vermutlich muss ich also auch noch für den User ein eigenes RPM installieren, das explizit gegen die librpm-4.4 gelinkt wird. Viele Funktionen aus der aktuellen librpm gab's nicht in der 4.4 und umgekehrt genauso. Die librpm wurde ja komplett überarbeitet, wie ich feststellen musste, also ich apt-rpm für SuSE 11.3. umbauen wollte.

 

[mime]

Ich hab übrigens einen Verdacht... ich denke, dass das von OpenSuSE 11.2 mitgelieferte RPM nicht mehr mit librpm-4.4 zusammenarbeitet, da sich ja die Struktur der librpm komplett geändert hat.

Wenn du diesen Thread nochmal liest, sollte daraus weitaus mehr als nur ein Verdacht werden.

Vermutlich muss ich also auch noch für den User ein eigenes RPM installieren, das explizit gegen die librpm-4.4 gelinkt wird.

Versuche vorher nochmal folgendes:

echo "macrofiles: ~/.rpmmacros" >> ~/.rpmrc

Dann wird die "~/.rpmmacros" tatsächlich wieder beachtet. Eventuell reicht das aber noch nicht...

HTH

Micha

 

[bitmuncher]

Also deine Lösung funktioniert soweit. Leider bringt mich das zum nächsten Problem...

error: cannot open Packages database in /home/user/.apt/.apt/var/lib/rpm

Auch --initdb oder --rebuilddb bringt keine Abhilfe und auch das Kopieren der globalen RPM-Package-DB in diesen Ordner ist nutzlos. Ich denke, wir müssen uns hier ein komplett neues Paketmanagement aufbauen. Ich starte jetzt noch einen Versuch und installiere für den User ein rpm-4.4.x, aber irgendwie habe ich das Gefühl, dass auch dies nichts bringen wird.

 

[mime]

error: cannot open Packages database in /home/user/.apt/.apt/var/lib/rpm

Auch --initdb oder --rebuilddb bringt keine Abhilfe und auch das Kopieren der globalen RPM-Package-DB in diesen Ordner ist nutzlos.

Das ist auch ein macro-problem.

~/.rpmrc

macrofiles: ~/.rpmmacros:/usr/lib/rpm/macros:/usr/lib/rpm/platform/pentium4-linux/macros:/usr/lib/rpm/suse/macros:/etc/rpm/macros.gconf2:/etc/rpm/macros.jpackage:etc/rpm/macros.kde4:/etc/rpm/macros.mkinitrd:/etc/rpm/macros.perl:/etc/rpm/macros.python:/etc/rpm/macros.tcl:/etc/rpm/macros.update-desktop-files:/etc/rpm/macros:/etc/rpm/pentium4-linux/macros

Dann steigt apt bei mir allerdings derzeit noch mit

pt-get: symbol lookup error: /home/mime/.apt/lib/libapt-pkg-libc6.9-6.so.2: undefined symbol: rpmCheckRpmlibProvides

aus...

HTH

Micha

 

[bitmuncher]

Fast... aber du hast mich mal wieder auf die richtige Spur gesetzt. Ich musste die globale /usr/lib/rpm/macros nach ~/.rpmmacros kopieren und dort meine userspezifischen Variablen entsprechen anpassen. Wenn ich den Macrofiles-Eintrag erweitert habe, hatte der User plötzlich die Paketliste für's System. Er soll aber ja nur seine eigene Paketliste sehen. Speziell %_dbpath und die ganzen Build-spezifischen Variablen mussten angepasst werden.

Vielen Dank!

 

[mime]

Wenn ich den Macrofiles-Eintrag erweitert habe, hatte der User plötzlich die Paketliste für's System. Er soll aber ja nur seine eigene Paketliste sehen. Speziell %_dbpath und die ganzen Build-spezifischen Variablen mussten angepasst werden.

Hmm...vielleicht hätte es auch gereicht "~/.rpmmacros" als letzten Eintrag in der ~/.rpmrc zu setzen.

macrofiles: /usr/lib/rpm/macros:[...]:~/.rpmmacros

Aber nun ja...funktioniert jetzt ja.

Micha

 

[bitmuncher]

Dieser Eintrag muss natürlich zusätzlich in der .rpmrc sein. Aber

macrofiles: macrofiles:~/.rpmmacros:/usr/lib/rpm/macros:/usr/lib/rpm/platform/pentium4-linux/macros:/usr/lib/rpm/suse/macros:/etc/rpm/macros.gconf2:/etc/rpm/macros.jpackage:etc/rpm/macros.kde4:/etc/rpm/macros.mkinitrd:/etc/rpm/macros.perl:/etc/rpm/macros.python:/etc/rpm/macros.tcl:/etc/rpm/macros.update-desktop-files:/etc/rpm/macros:/etc/rpm/pentium4-linux/macros

führt dazu, dass die global installierten RPMs für den User angezeigt werden. Er soll aber nur seine eigenen RPMs sehen können. Daher muss der Eintrag

macrofiles:~/.rpmmacros

lauten. Damit aber dann das Problem mit der nicht zu öffnenden Package-DB nicht auftaucht, müssen in der ~/.rpmmacros sämtliche Makros definiert sein, die auch in der globalen Makros-Datei sind, wobei eben die im Eingangsposting geschriebenen Werte angepasst werden müssen.

 

[mime]

macrofiles: macrofiles:~/.rpmmacros:/usr/lib/rpm/macros:/usr/lib/rpm/platform/pentium4-linux/macros:/usr/lib/rpm/suse/macros:/etc/rpm/macros.gconf2:/etc/rpm/macros.jpackage:etc/rpm/macros.kde4:/etc/rpm/macros.mkinitrd:/etc/rpm/macros.perl:/etc/rpm/macros.python:/etc/rpm/macros.tcl:/etc/rpm/macros.update-desktop-files:/etc/rpm/macros:/etc/rpm/pentium4-linux/macros

führt dazu, dass die global installierten RPMs für den User angezeigt werden.

Es ging ja mit einer 11.1 auch, da wurden die globalen Macros ja auch gelesen. Da dort die ~/.rpmmacros immer als letztes gelesen wird, könnte es sein, dass identische Makros sich gegenseitig überschreiben und der letzte "Gewinnt". Das müsste man also probieren, oder in den Sourcen mal schauen wie dort identische Makros priorisiert werden.

Er soll aber nur seine eigenen RPMs sehen können. Daher muss der Eintrag

macrofiles:~/.rpmmacros

lauten.

Wenn das reicht, ist das ja ok. Wenn der Entwickler aber Teile der z.B. SuSE-Makros benutzen muss/möchte...

Micha