Du bist nicht angemeldet.

#1 11.01.2020 13:21:45

brikler
Mitglied

wie löst man dateikonflikte?

grüß euch,

ich hab mir kwin selbstgebaut und beim installieren gibts einen datei konflikt mit glibc

Pakete (1) kwin-5.17.5-1

Gesamtgröße der installierten Pakete:  22,36 MiB
Größendifferenz der Aktualisierung:  -0,60 MiB

:: Installation fortsetzen? [J/n] 
(1/1) Prüfe Schlüssel im Schlüsselring                                                                         [##################################################################] 100%
(1/1) Überprüfe Paket-Integrität                                                                               [##################################################################] 100%
(1/1) Lade Paket-Dateien                                                                                       [##################################################################] 100%
(1/1) Prüfe auf Dateikonflikte                                                                                 [##################################################################] 100%
Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
kwin: /usr/lib64 existiert im Dateisystem (gehört zu glibc)
kwin: /usr/lib64/cmake/KWinDBusInterface/KWinDBusInterfaceConfig.cmake existiert im Dateisystem
kwin: /usr/lib64/kconf_update_bin/kwin5_update_default_rules existiert im Dateisystem
kwin: /usr/lib64/libkcmkwincommon.so.5 existiert im Dateisystem
kwin: /usr/lib64/libkdeinit5_kwin_rules_dialog.so existiert im Dateisystem
kwin: /usr/lib64/libkdeinit5_kwin_x11.so existiert im Dateisystem
kwin: /usr/lib64/libkwin.so.5 existiert im Dateisystem
kwin: /usr/lib64/libkwin4_effect_builtins.so existiert im Dateisystem
kwin: /usr/lib64/libkwin4_effect_builtins.so.1 existiert im Dateisystem
kwin: /usr/lib64/libkwin4_effect_builtins.so.1.0.0 existiert im Dateisystem
kwin: /usr/lib64/libkwineffects.so existiert im Dateisystem
kwin: /usr/lib64/libkwineffects.so.12 existiert im Dateisystem
kwin: /usr/lib64/libkwinglutils.so existiert im Dateisystem
kwin: /usr/lib64/libkwinglutils.so.12 existiert im Dateisystem
kwin: /usr/lib64/libkwinxrenderutils.so existiert im Dateisystem
kwin: /usr/lib64/libkwinxrenderutils.so.12 existiert im Dateisystem
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

natürlich kann ich kwin erst mal  entfernen, aber der datei konflikt mit /usr/lib64 bleibt, zwar gings dann mit --overwrite /usr/lib64 aber wenns dumm geht und alle pakete neu installiert werden müssen, dann hängt sichs  bei /usr/lib64 auf.

wo liegt da der fehler? bei glibc, kwin, oder ganz wo anders?

#die verpack teil von kwin
package() {
  cd build
  make DESTDIR="$pkgdir" install
}

Offline

#2 11.01.2020 17:07:23

ohshi1Ae
Gast

Re: wie löst man dateikonflikte?

brikler schrieb:

kwin: /usr/lib64 existiert im Dateisystem (gehört zu glibc)

Du musst dein Paket so bauen, dass nach /usr/lib installiert wird, weil /usr/lib64 ein symbolischer Link darauf ist, und deshalb kein Verzeichnis mit gleichem Namen angelegt werden kann.

#3 11.01.2020 18:04:52

brikler
Mitglied

Re: wie löst man dateikonflikte?

ich hab das PKGBUILD aus dem arch repo und mir bis jetzt da keine gedanken drum gemacht…
zum beispiel cairo hats genau so wie kwin, aber warum meckert da nicht pacman?

Offline

#4 11.01.2020 18:24:26

ohshi1Ae
Gast

Re: wie löst man dateikonflikte?

pacman meckert, weil es unter /usr/lib64 Dateien installieren soll, die es unter /usr/lib schon gibt, um das mal auf einen einfachen Nenner zu bringen.

Wenn du mit "pacman -Ql kwin" abfragst wirst du sehen, dass in der pacman-Datenbank die Dateien als sich unter /usr/lib befindlich registriert wurden. Und genau diese Dateien in diesem Verzeichnis würden bei einem Update des Pakets auch ohne Rückfrage  überschrieben. Aus der Sicht von pacman ist /usr/lib ein anderes Verzeichnis als /usr/lib64, bei dem Installationsversuch merkt es aber wegen des symbolischen Links auf /usr/lib, dass die Datei in /usr/lib64 schon existiert, und verweigert die Installation. Mit "pacman -Qo" kannst du auch noch einmal ausdrücklich pacman befragen, welche Datei zu welchem Paket gehört. Es darf immer genau nur einen Besitzer geben.

Die einzige vernünftige Maßnahme kann also nur sein, den Dateikonflikt durch Installation in das richtige Verzeichnis zu lösen.

#5 11.01.2020 18:40:37

stefanhusmann
Moderator

Re: wie löst man dateikonflikte?

An der cmake-Option

-DCMAKE_INSTALL_LIBEXECDIR=lib \

aus der build-Funktion hast du nicht gedreht? Die ist nämlich geanu dafür da, damit dies nicht passiert.

Online

#6 11.01.2020 19:01:01

brikler
Mitglied

Re: wie löst man dateikonflikte?

danke schön, aber ich hab am PKGBUILD überhaupt nichts verändert, warum auch? es funktioniert schließlich…

Beitrag geändert von brikler (11.01.2020 19:03:39)

Offline

#7 11.01.2020 19:47:52

ohshi1Ae
Gast

Re: wie löst man dateikonflikte?

Nein, es funktioniert nicht, sonst würdest du nicht versuchen, etwas nach /usr/lib64 zu installieren.

#8 11.01.2020 20:05:30

stefanhusmann
Moderator

Re: wie löst man dateikonflikte?

Wenn das Paket wirklich reproduzierbar nach /usr/lib64 installieren würde, würde es eben nicht richtig funktionieren.

Hast du mal virifiziert, ob /usr/lib64 bei dir auch tatsächlich ein Symlink auf /usr/lib ist?

Online

#9 11.01.2020 20:17:32

brikler
Mitglied

Re: wie löst man dateikonflikte?

mit "funktionieren" meinte ich: es lässt sich kompiliert und /usr/lib64 ist ein symlink auf /usr/lib

lrwxrwxrwx   1 root root    7 17.08.2019 22:15 lib64 -> usr/lib/
pkgname=kwin
pkgver=5.17.5
pkgrel=1
pkgdesc='An easy to use, but flexible, composited Window Manager'
arch=(x86_64)
url='https://www.kde.org/workspaces/plasmadesktop/'
license=(LGPL)
depends=(kscreenlocker xcb-util-cursor plasma-framework kcmutils breeze kinit qt5-sensors qt5-script)
makedepends=(extra-cmake-modules qt5-tools kdoctools)
optdepends=('qt5-virtualkeyboard: virtual keyboard support for kwin-wayland')
groups=(plasma)
source=("https://download.kde.org/stable/plasma/$pkgver/$pkgname-$pkgver.tar.xz"{,.sig})
install=$pkgname.install
sha256sums=('8517adaf8270d783aea7b3886d86b5abed6a5ec2b5c78b632479597d956baadc'
            'SKIP')
validpgpkeys=('2D1D5B0588357787DE9EE225EC94D18F7F05997E'  # Jonathan Riddell <jr@jriddell.org>
              '0AAC775BB6437A8D9AF7A3ACFE0784117FBCE11D'  # Bhushan Shah <bshah@kde.org>
              'D07BD8662C56CB291B316EB2F5675605C74E02CF'  # David Edmundson <davidedmundson@kde.org>
              '1FA881591C26B276D7A5518EEAAF29B42A678C20') # Marco Martin <notmart@gmail.com>

prepare() {
  mkdir -p build
}

build() {
  cd build
  cmake ../$pkgname-$pkgver \
    -DCMAKE_INSTALL_LIBEXECDIR=lib \
    -DBUILD_TESTING=OFF
  make
}

package() {
  cd build
  make DESTDIR="$pkgdir" install
}

https://projects.archlinux.de/svntogit/ … ages/kwin]

ich hab grad was am PKGBUILD verändert, ich hab die cmake direktiven aus dem 15.7-3 mit dazu getan und pacman hat nicht gemeckert:

cmake ../$pkgname-$pkgver \
     -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DKDE_INSTALL_LIBDIR=lib \
    -DKDE_INSTALL_SYSCONFDIR=/etc \
    -DKDE_INSTALL_LIBEXECDIR=lib \
    -DUDEV_RULES_INSTALL_DIR=/usr/lib/udev/rules.d \
     -DKDE_INSTALL_USE_QT_SYS_PATHS=ON "$@" \
#ab da aktuelles PKGBUILD
    -DCMAKE_INSTALL_LIBEXECDIR=lib \
    -DBUILD_TESTING=OFF 
  make

…aber so richtig toll ist das auch nicht:

==> WARNUNG: Paket enthält einen Verweis auf $srcdir
usr/lib/libkwinglutils.so.5.17.5
==> Erstelle Paket "kwin"...
  -> Erstelle .PKGINFO Datei...

Beitrag geändert von brikler (11.01.2020 20:40:35)

Offline

#10 11.01.2020 20:22:35

ohshi1Ae
Gast

Re: wie löst man dateikonflikte?

stefanhusmann schrieb:

Hast du mal virifiziert, ob /usr/lib64 bei dir auch tatsächlich ein Symlink auf /usr/lib ist?

Was ich auch reichlich seltsam finde ist, dass bei ihm pacman meldet, dass /usr/lib64 glibc gehört. Der Link wird eigentlich vom Paket "filesystem" angelegt, entweder ist da früher schon mal etwas schief gelaufen, oder es wurde Software an der Paketverwaltung vorbei installiert, die /usr/lib64 statt eines symbolischen Links als Ordner angelegt hat. Mit einem reinen Arch passiert so etwas nämlich nicht.

#11 11.01.2020 20:27:02

ohshi1Ae
Gast

Re: wie löst man dateikonflikte?

brikler schrieb:

mit "funktionieren" meinte ich: es lässt sich kompiliert und /usr/lib64 ist ein symlink auf /usr/lib

  
lrwxrwxrwx   1 root root    7 17.08.2019 22:15 lib64 -> usr/lib/

Es geht nicht um "lib64" sondern um "/usr/lib64".

#12 11.01.2020 20:46:41

brikler
Mitglied

Re: wie löst man dateikonflikte?

ohshi1Ae schrieb:
stefanhusmann schrieb:

Hast du mal virifiziert, ob /usr/lib64 bei dir auch tatsächlich ein Symlink auf /usr/lib ist?

Der Link wird eigentlich vom Paket "filesystem" angelegt, entweder ist da früher schon mal etwas schief gelaufen,

gut möglich, daß da was "verbogen" ist, gestern bekam ich beim starten den "freundlichen" hinweis "no working init found", also hab ich im chroot alle pakete neu installiert, dann konnte ich wieder wie gewohnt booten

ohshi1Ae schrieb:
brikler schrieb:

mit "funktionieren" meinte ich: es lässt sich kompiliert und /usr/lib64 ist ein symlink auf /usr/lib

  
lrwxrwxrwx   1 root root    7 17.08.2019 22:15 lib64 -> usr/lib/

Es geht nicht um "lib64" sondern um "/usr/lib64".

[tom@donar ~]$ ls -l /usr/
insgesamt 318
drwxr-xr-x   3 root root 118784 11.01.2020 19:33 bin/
drwxr-xr-x 293 root root  24576 11.01.2020 19:33 include/
drwxr-xr-x 127 root root 249856 11.01.2020 19:42 lib/
drwxr-xr-x   5 root root   4096 11.01.2020 11:14 lib32/
drwxr-xr-x   2 root root   3488 11.01.2020 17:14 libexec/
drwxr-xr-x  11 root root   3488 27.01.2019 19:10 local/
drwxr-xr-x   3 root root   3488 10.04.2019 15:56 man/
drwxr-xr-x   2 root root   8192 11.01.2020 19:26 sbin/
drwxr-xr-x 202 root root   8192 11.01.2020 18:12 share/
drwxr-xr-x   3 root root   3488 05.01.2020 18:24 src/
lrwxrwxrwx   1 root root     12 27.01.2019 20:48 depmod -> /sbin/depmod*
lrwxrwxrwx   1 root root      3 17.08.2019 22:15 lib64 -> lib/

Beitrag geändert von brikler (11.01.2020 20:50:32)

Offline

#13 11.01.2020 21:10:25

ohshi1Ae
Gast

Re: wie löst man dateikonflikte?

Da ist noch mehr kaputt. /usr/sbin müsste z. B. auf /usr/bin verlinkt sein, das ist bei dir aber ein Verzeichnis. Da liegt übrigens auch ganz nebenbei noch ein Link zu "init", was möglicherweise auch den Fehler "no working init found" erklären könnte, wenn /sbin leer war, bzw. nicht auf das richtige Verzeichnis mit den nötigen Inhalten verweist.

Da müsstest du mal in dich gehen und versuchen dich zu erinnern, was du vor dem Bootproblem gemacht hast, denn das kommt ja auch nicht von ungefähr.

#14 11.01.2020 22:20:08

brikler
Mitglied

Re: wie löst man dateikonflikte?

/sbin bzw /usr/sbin war nicht leer und der link von /sbin/init zu /usr/lib/systemd/systemd war richtig gesetzt.

mit dem 5.4 er kernel hatte und hab ich ärger mit der graphik, da hab ich ihn mal "abgewürgt", da kommt wahrscheinlich der datenverlust her.
damals hab ich mir mit einem "pacman -S `pacman -Qqn`" beholfen, wie ach dieses mal, mit dem selben problem… jetzt hab ich hald danach gefragt.

Offline

#15 11.01.2020 22:55:23

ohshi1Ae
Gast

Re: wie löst man dateikonflikte?

brikler schrieb:

/sbin bzw /usr/sbin war nicht leer und der link von /sbin/init zu /usr/lib/systemd/systemd war richtig gesetzt.

/usr/lib/systemd/systemd ist aber aus /sbin nicht erreichbar, wenn es nicht auf /usr/bin zeigt. Und für /usr/sbin gilt das gleiche. Deswegen ist es definitiv falsch, wenn /sbin ein statisches Verzeichnis und kein symbolischer Link ist.

Und alles, was jetzt über pacman nach /usr/bin installiert wird, würde nicht mehr in /sbin erscheinen, und Anwendungen, die das auf /sbin erwarten, fahren dann vor die Wand. Installier doch noch mal das Paket "filesystem", dann wirst du schon sehen, wo es bei so einer Verzeichnisstruktur überall kracht.

#16 12.01.2020 10:49:14

brikler
Mitglied

Re: wie löst man dateikonflikte?

[tom@donar ~]$ sudo pacman -S filesystem
[sudo] Passwort für tom: 
Warnung: filesystem-2019.08-1 ist aktuell -- Reinstalliere
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...

Pakete (1) filesystem-2019.08-1

Gesamtgröße der installierten Pakete:  0,24 MiB
Größendifferenz der Aktualisierung:  0,00 MiB

:: Installation fortsetzen? [J/n] 
(1/1) Prüfe Schlüssel im Schlüsselring                        [#################################] 100%
(1/1) Überprüfe Paket-Integrität                              [#################################] 100%
(1/1) Lade Paket-Dateien                                      [#################################] 100%
(1/1) Prüfe auf Dateikonflikte                                [#################################] 100%
(1/1) Überprüfe verfügbaren Festplattenspeicher               [#################################] 100%
Warnung: konnte Dateiinformationen für var/log/old/ nicht ermitteln
:: Verarbeite Paketänderungen...
(1/1) Installiere filesystem                                  [#################################] 100%
:: Starte post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...

hoffentlich war es das jetzt und hab hoffentlich wieder ruhe.

@ohshi1Ae
danke schön smile

Offline

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums