[arch-general] lib -> usr/lib
I laugh away this trouble. Is there any information about the advantages of lib -> usr/lib? I like to read it, after I finished the following occupational therapy [1]. I suspect that if I won't do it now, I have to restore my Arch from a backup? Or can I shutdown and startup anyway? Regards, Ralf [1] [root@archlinux spinymouse]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 37.58 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [######################################] 100% (1/1) loading package files [######################################] 100% (1/1) checking for file conflicts [######################################] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. [root@archlinux spinymouse]# grep '^lib/' /var/lib/pacman/local/*/files /var/lib/pacman/local/glibc-2.15-12/files:lib/ /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-linux-x86-64.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libSegFault.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libc-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libc.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libm-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libm.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libmemusage.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libpcprofile.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread.so.0 /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/librt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/librt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db-1.0.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil.so.1 /var/lib/pacman/local/ld-lsb-3-3/files:lib/ /var/lib/pacman/local/ld-lsb-3-3/files:lib/ld-lsb.so.3 /var/lib/pacman/local/udev-compat-180-1/files:lib/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/autofs /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/btrfs-control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/microcode /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/fuse /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/tun /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ppp /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/snd/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/snd/seq /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/snd/timer /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/uinput /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/rules.d/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/rules.d/30-kernel-compat.rules [root@archlinux spinymouse]# find /lib -exec pacman -Qo -- {} + error: cannot determine ownership of directory '/lib' /lib/libm-2.15.so is owned by glibc 2.15-12 /lib/libc-2.15.so is owned by glibc 2.15-12 /lib/ld-2.15.so is owned by glibc 2.15-12 /lib/libBrokenLocale-2.15.so is owned by glibc 2.15-12 /lib/libcidn.so.1 is owned by glibc 2.15-12 /lib/libnss_compat-2.15.so is owned by glibc 2.15-12 /lib/libnss_nisplus-2.15.so is owned by glibc 2.15-12 /lib/libutil.so.1 is owned by glibc 2.15-12 error: cannot determine ownership of directory '/lib/modules' error: cannot determine ownership of directory '/lib/modules/3.1.9-1-ARCH' error: No package owns /lib/modules/3.1.9-1-ARCH/modules.isapnpmap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.seriomap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.ccwmap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.ofmap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.inputmap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.usbmap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.ieee1394map error: No package owns /lib/modules/3.1.9-1-ARCH/modules.pcimap error: cannot determine ownership of directory '/lib/modules/3.2.6-2-ARCH' error: No package owns /lib/modules/3.2.6-2-ARCH/modules.dep.bin error: No package owns /lib/modules/3.2.6-2-ARCH/modules.symbols error: No package owns /lib/modules/3.2.6-2-ARCH/modules.alias.bin error: No package owns /lib/modules/3.2.6-2-ARCH/modules.alias error: No package owns /lib/modules/3.2.6-2-ARCH/modules.devname error: No package owns /lib/modules/3.2.6-2-ARCH/modules.builtin.bin error: No package owns /lib/modules/3.2.6-2-ARCH/modules.dep error: No package owns /lib/modules/3.2.6-2-ARCH/modules.softdep error: No package owns /lib/modules/3.2.6-2-ARCH/modules.symbols.bin error: cannot determine ownership of directory '/lib/modules/3.1.9-2-ARCH' error: No package owns /lib/modules/3.1.9-2-ARCH/modules.isapnpmap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.seriomap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.ccwmap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.ofmap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.inputmap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.usbmap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.ieee1394map error: No package owns /lib/modules/3.1.9-2-ARCH/modules.pcimap error: cannot determine ownership of directory '/lib/modules/3.0-rt' error: cannot determine ownership of directory '/lib/modules/3.0-rt/extramodules' error: No package owns /lib/modules/3.0-rt/extramodules/vboxnetadp.ko.gz error: No package owns /lib/modules/3.0-rt/extramodules/vboxdrv.ko.gz error: No package owns /lib/modules/3.0-rt/extramodules/vboxpci.ko.gz error: No package owns /lib/modules/3.0-rt/extramodules/vboxnetflt.ko.gz error: cannot determine ownership of directory '/lib/modules/extramodules-3.4-rt' error: No package owns /lib/modules/extramodules-3.4-rt/vboxnetadp.ko.gz error: No package owns /lib/modules/extramodules-3.4-rt/vboxdrv.ko.gz error: No package owns /lib/modules/extramodules-3.4-rt/vboxpci.ko.gz error: No package owns /lib/modules/extramodules-3.4-rt/vboxnetflt.ko.gz error: cannot determine ownership of directory '/lib/modules/3.4.2-rt10-1-rt' error: No package owns /lib/modules/3.4.2-rt10-1-rt/build /lib/libSegFault.so is owned by glibc 2.15-12 /lib/libnss_db-2.15.so is owned by glibc 2.15-12 /lib/libnss_nis.so.2 is owned by glibc 2.15-12 error: cannot determine ownership of directory '/lib/firmware' error: cannot determine ownership of directory '/lib/firmware/RTL8192SU' error: No package owns /lib/firmware/RTL8192SU/rtl8192sfw.bin /lib/libc.so.6 is owned by glibc 2.15-12 /lib/libpthread-2.15.so is owned by glibc 2.15-12 /lib/libanl.so.1 is owned by glibc 2.15-12 /lib/libnsl.so.1 is owned by glibc 2.15-12 /lib/libnss_compat.so.2 is owned by glibc 2.15-12 /lib/libthread_db.so.1 is owned by glibc 2.15-12 /lib/libnss_dns.so.2 is owned by glibc 2.15-12 /lib/libresolv.so.2 is owned by glibc 2.15-12 /lib/libm.so.6 is owned by glibc 2.15-12 /lib/libthread_db-1.0.so is owned by glibc 2.15-12 /lib/libnss_hesiod-2.15.so is owned by glibc 2.15-12 /lib/libnss_nis-2.15.so is owned by glibc 2.15-12 /lib/libnss_files-2.15.so is owned by glibc 2.15-12 /lib/librt.so.1 is owned by glibc 2.15-12 /lib/libpcprofile.so is owned by glibc 2.15-12 /lib/libpthread.so.0 is owned by glibc 2.15-12 /lib/libcrypt.so.1 is owned by glibc 2.15-12 /lib/libnss_files.so.2 is owned by glibc 2.15-12 /lib/libdl.so.2 is owned by glibc 2.15-12 /lib/libBrokenLocale.so.1 is owned by glibc 2.15-12 /lib/libresolv-2.15.so is owned by glibc 2.15-12 /lib/libutil-2.15.so is owned by glibc 2.15-12 /lib/libnss_db.so.2 is owned by glibc 2.15-12 /lib/libanl-2.15.so is owned by glibc 2.15-12 /lib/ld-linux-x86-64.so.2 is owned by glibc 2.15-12 /lib/libcrypt-2.15.so is owned by glibc 2.15-12 /lib/libnss_hesiod.so.2 is owned by glibc 2.15-12 /lib/librt-2.15.so is owned by glibc 2.15-12 /lib/libdl-2.15.so is owned by glibc 2.15-12 error: cannot determine ownership of directory '/lib/udev' error: cannot determine ownership of directory '/lib/udev/rules.d' /lib/udev/rules.d/30-kernel-compat.rules is owned by udev-compat 180-1 error: cannot determine ownership of directory '/lib/udev/devices' /lib/udev/devices/uinput is owned by udev-compat 180-1 /lib/udev/devices/fuse is owned by udev-compat 180-1 error: cannot determine ownership of directory '/lib/udev/devices/cpu' /lib/udev/devices/cpu/microcode is owned by udev-compat 180-1 error: cannot determine ownership of directory '/lib/udev/devices/net' /lib/udev/devices/net/tun is owned by udev-compat 180-1 error: cannot determine ownership of directory '/lib/udev/devices/snd' /lib/udev/devices/snd/timer is owned by udev-compat 180-1 /lib/udev/devices/snd/seq is owned by udev-compat 180-1 /lib/udev/devices/btrfs-control is owned by udev-compat 180-1 /lib/udev/devices/ppp is owned by udev-compat 180-1 error: cannot determine ownership of directory '/lib/udev/devices/mapper' /lib/udev/devices/mapper/control is owned by udev-compat 180-1 /lib/udev/devices/autofs is owned by udev-compat 180-1 /lib/libcidn-2.15.so is owned by glibc 2.15-12 /lib/libnss_dns-2.15.so is owned by glibc 2.15-12 /lib/libnss_nisplus.so.2 is owned by glibc 2.15-12 /lib/libmemusage.so is owned by glibc 2.15-12 /lib/libnsl-2.15.so is owned by glibc 2.15-12
On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote:
I laugh away this trouble. Is there any information about the advantages of lib -> usr/lib? I like to read it, after I finished the following occupational therapy [1]. I suspect that if I won't do it now, I have to restore my Arch from a backup? Or can I shutdown and startup anyway?
Regards, Ralf
[1] [root@archlinux spinymouse]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts...
Targets (1): glibc-2.16.0-2
Total Installed Size: 37.58 MiB Net Upgrade Size: 0.83 MiB
Proceed with installation? [Y/n] (1/1) checking package integrity [######################################] 100% (1/1) loading package files [######################################] 100% (1/1) checking for file conflicts [######################################] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. [root@archlinux spinymouse]# grep '^lib/' /var/lib/pacman/local/*/files /var/lib/pacman/local/glibc-2.15-12/files:lib/ /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-linux-x86-64.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libSegFault.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libc-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libc.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libm-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libm.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libmemusage.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libpcprofile.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread.so.0 /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/librt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/librt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db-1.0.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil.so.1 /var/lib/pacman/local/ld-lsb-3-3/files:lib/ /var/lib/pacman/local/ld-lsb-3-3/files:lib/ld-lsb.so.3 /var/lib/pacman/local/udev-compat-180-1/files:lib/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/autofs /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/btrfs-control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/microcode /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/fuse /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/tun /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ppp /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/snd/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/snd/seq /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/snd/timer /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/uinput /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/rules.d/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/rules.d/30-kernel-compat.rules [root@archlinux spinymouse]# find /lib -exec pacman -Qo -- {} + error: cannot determine ownership of directory '/lib' /lib/libm-2.15.so is owned by glibc 2.15-12 /lib/libc-2.15.so is owned by glibc 2.15-12 /lib/ld-2.15.so is owned by glibc 2.15-12 /lib/libBrokenLocale-2.15.so is owned by glibc 2.15-12 /lib/libcidn.so.1 is owned by glibc 2.15-12 /lib/libnss_compat-2.15.so is owned by glibc 2.15-12 /lib/libnss_nisplus-2.15.so is owned by glibc 2.15-12 /lib/libutil.so.1 is owned by glibc 2.15-12 error: cannot determine ownership of directory '/lib/modules' error: cannot determine ownership of directory '/lib/modules/3.1.9-1-ARCH' error: No package owns /lib/modules/3.1.9-1-ARCH/modules.isapnpmap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.seriomap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.ccwmap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.ofmap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.inputmap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.usbmap error: No package owns /lib/modules/3.1.9-1-ARCH/modules.ieee1394map error: No package owns /lib/modules/3.1.9-1-ARCH/modules.pcimap error: cannot determine ownership of directory '/lib/modules/3.2.6-2-ARCH' error: No package owns /lib/modules/3.2.6-2-ARCH/modules.dep.bin error: No package owns /lib/modules/3.2.6-2-ARCH/modules.symbols error: No package owns /lib/modules/3.2.6-2-ARCH/modules.alias.bin error: No package owns /lib/modules/3.2.6-2-ARCH/modules.alias error: No package owns /lib/modules/3.2.6-2-ARCH/modules.devname error: No package owns /lib/modules/3.2.6-2-ARCH/modules.builtin.bin error: No package owns /lib/modules/3.2.6-2-ARCH/modules.dep error: No package owns /lib/modules/3.2.6-2-ARCH/modules.softdep error: No package owns /lib/modules/3.2.6-2-ARCH/modules.symbols.bin error: cannot determine ownership of directory '/lib/modules/3.1.9-2-ARCH' error: No package owns /lib/modules/3.1.9-2-ARCH/modules.isapnpmap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.seriomap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.ccwmap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.ofmap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.inputmap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.usbmap error: No package owns /lib/modules/3.1.9-2-ARCH/modules.ieee1394map error: No package owns /lib/modules/3.1.9-2-ARCH/modules.pcimap error: cannot determine ownership of directory '/lib/modules/3.0-rt' error: cannot determine ownership of directory '/lib/modules/3.0-rt/extramodules' error: No package owns /lib/modules/3.0-rt/extramodules/vboxnetadp.ko.gz error: No package owns /lib/modules/3.0-rt/extramodules/vboxdrv.ko.gz error: No package owns /lib/modules/3.0-rt/extramodules/vboxpci.ko.gz error: No package owns /lib/modules/3.0-rt/extramodules/vboxnetflt.ko.gz error: cannot determine ownership of directory '/lib/modules/extramodules-3.4-rt' error: No package owns /lib/modules/extramodules-3.4-rt/vboxnetadp.ko.gz error: No package owns /lib/modules/extramodules-3.4-rt/vboxdrv.ko.gz error: No package owns /lib/modules/extramodules-3.4-rt/vboxpci.ko.gz error: No package owns /lib/modules/extramodules-3.4-rt/vboxnetflt.ko.gz error: cannot determine ownership of directory '/lib/modules/3.4.2-rt10-1-rt' error: No package owns /lib/modules/3.4.2-rt10-1-rt/build /lib/libSegFault.so is owned by glibc 2.15-12 /lib/libnss_db-2.15.so is owned by glibc 2.15-12 /lib/libnss_nis.so.2 is owned by glibc 2.15-12 error: cannot determine ownership of directory '/lib/firmware' error: cannot determine ownership of directory '/lib/firmware/RTL8192SU' error: No package owns /lib/firmware/RTL8192SU/rtl8192sfw.bin /lib/libc.so.6 is owned by glibc 2.15-12 /lib/libpthread-2.15.so is owned by glibc 2.15-12 /lib/libanl.so.1 is owned by glibc 2.15-12 /lib/libnsl.so.1 is owned by glibc 2.15-12 /lib/libnss_compat.so.2 is owned by glibc 2.15-12 /lib/libthread_db.so.1 is owned by glibc 2.15-12 /lib/libnss_dns.so.2 is owned by glibc 2.15-12 /lib/libresolv.so.2 is owned by glibc 2.15-12 /lib/libm.so.6 is owned by glibc 2.15-12 /lib/libthread_db-1.0.so is owned by glibc 2.15-12 /lib/libnss_hesiod-2.15.so is owned by glibc 2.15-12 /lib/libnss_nis-2.15.so is owned by glibc 2.15-12 /lib/libnss_files-2.15.so is owned by glibc 2.15-12 /lib/librt.so.1 is owned by glibc 2.15-12 /lib/libpcprofile.so is owned by glibc 2.15-12 /lib/libpthread.so.0 is owned by glibc 2.15-12 /lib/libcrypt.so.1 is owned by glibc 2.15-12 /lib/libnss_files.so.2 is owned by glibc 2.15-12 /lib/libdl.so.2 is owned by glibc 2.15-12 /lib/libBrokenLocale.so.1 is owned by glibc 2.15-12 /lib/libresolv-2.15.so is owned by glibc 2.15-12 /lib/libutil-2.15.so is owned by glibc 2.15-12 /lib/libnss_db.so.2 is owned by glibc 2.15-12 /lib/libanl-2.15.so is owned by glibc 2.15-12 /lib/ld-linux-x86-64.so.2 is owned by glibc 2.15-12 /lib/libcrypt-2.15.so is owned by glibc 2.15-12 /lib/libnss_hesiod.so.2 is owned by glibc 2.15-12 /lib/librt-2.15.so is owned by glibc 2.15-12 /lib/libdl-2.15.so is owned by glibc 2.15-12 error: cannot determine ownership of directory '/lib/udev' error: cannot determine ownership of directory '/lib/udev/rules.d' /lib/udev/rules.d/30-kernel-compat.rules is owned by udev-compat 180-1 error: cannot determine ownership of directory '/lib/udev/devices' /lib/udev/devices/uinput is owned by udev-compat 180-1 /lib/udev/devices/fuse is owned by udev-compat 180-1 error: cannot determine ownership of directory '/lib/udev/devices/cpu' /lib/udev/devices/cpu/microcode is owned by udev-compat 180-1 error: cannot determine ownership of directory '/lib/udev/devices/net' /lib/udev/devices/net/tun is owned by udev-compat 180-1 error: cannot determine ownership of directory '/lib/udev/devices/snd' /lib/udev/devices/snd/timer is owned by udev-compat 180-1 /lib/udev/devices/snd/seq is owned by udev-compat 180-1 /lib/udev/devices/btrfs-control is owned by udev-compat 180-1 /lib/udev/devices/ppp is owned by udev-compat 180-1 error: cannot determine ownership of directory '/lib/udev/devices/mapper' /lib/udev/devices/mapper/control is owned by udev-compat 180-1 /lib/udev/devices/autofs is owned by udev-compat 180-1 /lib/libcidn-2.15.so is owned by glibc 2.15-12 /lib/libnss_dns-2.15.so is owned by glibc 2.15-12 /lib/libnss_nisplus.so.2 is owned by glibc 2.15-12 /lib/libmemusage.so is owned by glibc 2.15-12 /lib/libnsl-2.15.so is owned by glibc 2.15-12
remove udev-compat it is old, either update ld-lsb from aur or remove it as for the find, remove any un owned files from anything under /lib. then remove any empty directories then update
On Tue, 2012-07-24 at 15:52 -0400, Daniel Wallace wrote:
remove udev-compat it is old, either update ld-lsb from aur or remove it
as for the find, remove any un owned files from anything under /lib. then remove any empty directories
then update
Thank you :) at least it's not bad that I'm forced to get rid of some old unneeded stuff ;). Regards, Ralf
On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote:
I laugh away this trouble. Is there any information about the advantages of lib -> usr/lib?
anyone likes to answer this question? -ken
On Thu, Jul 26, 2012 at 09:19:59AM +0800, Ken CC wrote:
On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote:
I laugh away this trouble. Is there any information about the advantages of lib -> usr/lib?
anyone likes to answer this question?
-ken
this was the thread on arch-dev-public talking about it http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.htm...
On Thu, Jul 26, 2012 at 09:19:59AM +0800, Ken CC wrote:
On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote:
I laugh away this trouble. Is there any information about the advantages of lib -> usr/lib?
anyone likes to answer this question?
-ken
I beleive its a question of How is the filesytem structure and its distributed nature/capabilities relevant today i.e the need for /bin or /lib even.
I beleive its a question of
How is the filesytem structure and its distributed nature/capabilities relevant today
i.e the need for /bin or /lib even.
If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in.
If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in.
well no the point is to have a single top-level directory for a single purpose. so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state). Let me paste this here: » The merged directory /usr, containing almost the entire vendor-supplied operating system resources, offers us a number of new features regarding OS snapshotting and options for enterprise environments for network sharing or running multiple guests on one host. Most of this is much harder to accomplish, or even impossible, with the current arbitrary split of tools across multiple directories. With all vendor-supplied OS resources in a single directory /usr they may be shared atomically, snapshots of them become atomic, and the file system may be made read-only as a single unit. « Well, /opt would have to go soon, too -- дамјан
If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in.
well no the point is to have a single top-level directory for a single purpose.
so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state).
My variant is: /lib -> /usr/lib /bin -> /usr/bin /sbin -> /usr/bin After that rename: /usr to /system /etc to /config /dev to /device Why not using clear (and not so short) names to indicate real purpose!
On Thu, Jul 26, 2012 at 11:30 AM, <brainworker@lavabit.com> wrote:
If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in.
well no the point is to have a single top-level directory for a single purpose.
so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state).
My variant is:
/lib -> /usr/lib /bin -> /usr/bin /sbin -> /usr/bin
After that rename: /usr to /system /etc to /config /dev to /device
Why not using clear (and not so short) names to indicate real purpose!
Yes, why not just turn the device into android... renaming for the sake of renaming serves no purpose. There are real benefits to moving /lib and /bin into /usr, renaming folders does not provide any real benefits.
On Thu, 2012-07-26 at 13:01 +0800, Oon-Ee Ng wrote:
On Thu, Jul 26, 2012 at 11:30 AM, <brainworker@lavabit.com> wrote:
If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in.
well no the point is to have a single top-level directory for a single purpose.
so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state).
My variant is:
/lib -> /usr/lib /bin -> /usr/bin /sbin -> /usr/bin
After that rename: /usr to /system /etc to /config /dev to /device
Why not using clear (and not so short) names to indicate real purpose!
Yes, why not just turn the device into android... renaming for the sake of renaming serves no purpose. There are real benefits to moving /lib and /bin into /usr, renaming folders does not provide any real benefits.
Today I hope we'll keep /usr, /etc, /dev etc., but when I started to use Linux /system, /config would be easier to understand. Well, between /dev and /device there's no difference, even for my completely broken English. However, I'm not sure if "brainworker" is serious or sarcastic ;p. Regards, Ralf
On Thu, Jul 26, 2012 at 8:01 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Thu, Jul 26, 2012 at 11:30 AM, <brainworker@lavabit.com> wrote:
If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in.
well no the point is to have a single top-level directory for a single purpose.
so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state).
My variant is:
/lib -> /usr/lib /bin -> /usr/bin /sbin -> /usr/bin
After that rename: /usr to /system /etc to /config /dev to /device
Why not using clear (and not so short) names to indicate real purpose!
Yes, why not just turn the device into android... renaming for the sake of renaming serves no purpose. There are real benefits to moving /lib and /bin into /usr, renaming folders does not provide any real benefits.
Actually, having more descriptive names would ease the burden on the new users... Leading to less confusion and less mailing list posts regarding where they need to look for config files. Of course, this will also mean a lot of nitpicking regarding what the symlinks should be named... M
On Wed, Jul 25, 2012 at 11:30:06PM -0400, brainworker@lavabit.com wrote:
If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in.
well no the point is to have a single top-level directory for a single purpose.
so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state).
My variant is:
/lib -> /usr/lib /bin -> /usr/bin /sbin -> /usr/bin
After that rename: /usr to /system /etc to /config /dev to /device
Why not using clear (and not so short) names to indicate real purpose!
Things are tried and true... But things have changed alot in recent years. For example network/internet bandwidth or the size and speed of storage medium. AND re-naming things is not keeping it simple... or is it? No its not.. So... =)
If everything is to end up in /usr, then I'd argue that this makes /usr superfluous. If merging is to be done, then IMO things should be moved out of /usr, not moved in.
well no the point is to have a single top-level directory for a single
On Thursday 26 Jul 2012 05:13:39 Damjan wrote: purpose.
so distribution provided files will go to /usr, local-system configuration in /etc, /run is for runtime state, /var is the local-system state (the non-ephemeral state).
Let me paste this here: » The merged directory /usr, containing almost the entire vendor-
supplied
operating system resources, offers us a number of new features regarding OS snapshotting and options for enterprise environments for network sharing or running multiple guests on one host. Most of this is much harder to accomplish, or even impossible, with the current arbitrary split of tools across multiple directories.
With all vendor-supplied OS resources in a single directory /usr they may be shared atomically, snapshots of them become atomic, and the file system may be made read-only as a single unit. «
Well, /opt would have to go soon, too
Why will /opt have to go? I always though /opt was for installing custom software which you do not want to mix with other software (for example I have MATLAB and similar stuff installed there with each of them in its separate folder) and I guess, that is the one and only use of /opt and there is no other directory which does something similar, except for if you are talking about /local but then, /local has the purpose of being /local, it can be vendor- supplied local program which are specific to the machine and it will have /bin /etc /lib and stuff? -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On Thu, 2012-07-26 at 12:23 +0530, Jayesh Badwaik wrote:
Why will /opt have to go? I always though /opt was for installing custom software which you do not want to mix with other software (for example I have MATLAB and similar stuff installed there with each of them in its separate folder) and I guess, that is the one and only use of /opt and there is no other directory which does something similar, except for if you are talking about /local but then, /local has the purpose of being /local, it can be vendor- supplied local program which are specific to the machine and it will have /bin /etc /lib and stuff?
Good point! Assumed I wish to use software "Xy version 1" and I want to install "Xy version alpha 2" too? Until now /opt is the place to do so.
On Thu, 2012-07-26 at 09:09 +0200, Ralf Mardorf wrote:
On Thu, 2012-07-26 at 12:23 +0530, Jayesh Badwaik wrote:
Why will /opt have to go? I always though /opt was for installing custom software which you do not want to mix with other software (for example I have MATLAB and similar stuff installed there with each of them in its separate folder) and I guess, that is the one and only use of /opt and there is no other directory which does something similar, except for if you are talking about /local but then, /local has the purpose of being /local, it can be vendor- supplied local program which are specific to the machine and it will have /bin /etc /lib and stuff?
Good point!
Assumed I wish to use software "Xy version 1" and I want to install "Xy version alpha 2" too? Until now /opt is the place to do so.
PS: /local isn't the right place to install one of two different versions of the same software! This will cause conflicts!
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik <jayesh.badwaik90@gmail.com>wrote:
Why will /opt have to go?
Well, then: /opt -> /usr/opt And everyone will be happy :) BTW, will there be the move from /bin to /usr/bin in the foreseeable future? -- Rodrigo
Rodrigo Rivas <rodrigorivascosta@gmail.com> on Thu, 2012/07/26 10:18:
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik <jayesh.badwaik90@gmail.com>wrote:
Why will /opt have to go?
Well, then:
/opt -> /usr/opt
And everyone will be happy :)
BTW, will there be the move from /bin to /usr/bin in the foreseeable future?
Good question. I can not remember having seen and recent plans on it. This gives an idea about which packages still have files in /bin/: $ pacman -Qoq /bin/* | sort | uniq And the same for /sbin/: $ pacman -Qoq /sbin/* | sort | uniq No single file that does not belong to a package here... Good conditions for a smooth update. ;) -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
On Thu, Jul 26, 2012 at 3:27 AM, Christian Hesse <list@eworm.de> wrote:
Rodrigo Rivas <rodrigorivascosta@gmail.com> on Thu, 2012/07/26 10:18:
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik <jayesh.badwaik90@gmail.com>wrote:
Why will /opt have to go?
Well, then:
/opt -> /usr/opt
And everyone will be happy :)
BTW, will there be the move from /bin to /usr/bin in the foreseeable future?
Good question. I can not remember having seen and recent plans on it.
This gives an idea about which packages still have files in /bin/:
$ pacman -Qoq /bin/* | sort | uniq
And the same for /sbin/:
$ pacman -Qoq /sbin/* | sort | uniq
No single file that does not belong to a package here... Good conditions for a smooth update. ;)
i've got nothing to back this up, but i'm guessing this one is going to be a little trickier ... mainly because there are multiple packages that are *expected* to exist in /bin. `bash` (sh) and `coreutils` are the two major ones that come to mind. i expect pacman does not fork out to external processes, and can handle the switch itself, but it's not as easy as the incremental lib -> usr/lib update (which affects nothing) ... i expect there will be a final switcharoo at the end where 2+ packages must all be moved in one fell swoop. Tom? others? i too am curious of the progress or experiences thus far. -- C Anthony
On Thu, Jul 26, 2012 at 10:33 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
i've got nothing to back this up, but i'm guessing this one is going to be a little trickier ... mainly because there are multiple packages that are *expected* to exist in /bin. `bash` (sh) and `coreutils` are the two major ones that come to mind.
i expect pacman does not fork out to external processes, and can handle the switch itself, but it's not as easy as the incremental lib -> usr/lib update (which affects nothing) ... i expect there will be a final switcharoo at the end where 2+ packages must all be moved in one fell swoop.
Tom? others? i too am curious of the progress or experiences thus far.
This was the original proposal: <http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html>. I just re-read it, noticing that I wrote about the move of /lib that it has "no real risks or downsides". Feel free to point and laugh. I have a patch against pacman which should make it able to deal with /bin/sh being in /usr/bin/, which I think is the only issue before we could make such a move (as pacman does call sh to run post-upgrade scripts and similar). I guess no one is in any hurry to make this move though, people probably want to catch their breath after the /lib move ;-) Cheers, Tom
On Thu, Jul 26, 2012 at 6:03 AM, Tom Gundersen <teg@jklm.no> wrote:
On Thu, Jul 26, 2012 at 10:33 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
i've got nothing to back this up, but i'm guessing this one is going to be a little trickier ... mainly because there are multiple packages that are *expected* to exist in /bin. `bash` (sh) and `coreutils` are the two major ones that come to mind.
i expect pacman does not fork out to external processes, and can handle the switch itself, but it's not as easy as the incremental lib -> usr/lib update (which affects nothing) ... i expect there will be a final switcharoo at the end where 2+ packages must all be moved in one fell swoop.
Tom? others? i too am curious of the progress or experiences thus far.
This was the original proposal: <http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html>. I just re-read it, noticing that I wrote about the move of /lib that it has "no real risks or downsides". Feel free to point and laugh.
I have a patch against pacman which should make it able to deal with /bin/sh being in /usr/bin/, which I think is the only issue before we could make such a move (as pacman does call sh to run post-upgrade scripts and similar).
I guess no one is in any hurry to make this move though, people probably want to catch their breath after the /lib move ;-)
heh, yeah i'm sure you're right about that :-) this might be slightly hacky, but what if packages were moved one at a time, and each time the `filesystem` package grew symlinks from `/bin/{some-binary}` -> `/usr/bin/{some-binary}`? then, when /bin has nothing but symlinks, you can upgrade the filesystem package, dropping all the link and replacing `/bin` with symlinks to `/usr/bin`. it would be a little ugly, with filesystem absobing some 200+ links, but nothing work break in the interim (i think ;-). -- C Anthony
Christian Hesse <list@eworm.de> on Thu, 2012/07/26 10:27:
Rodrigo Rivas <rodrigorivascosta@gmail.com> on Thu, 2012/07/26 10:18:
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik <jayesh.badwaik90@gmail.com>wrote:
Why will /opt have to go?
Well, then:
/opt -> /usr/opt
And everyone will be happy :)
BTW, will there be the move from /bin to /usr/bin in the foreseeable future?
Good question. I can not remember having seen and recent plans on it.
This gives an idea about which packages still have files in /bin/:
$ pacman -Qoq /bin/* | sort | uniq
And the same for /sbin/:
$ pacman -Qoq /sbin/* | sort | uniq
No single file that does not belong to a package here... Good conditions for a smooth update. ;)
That said i still have two files linked from /usr/sbin/ to /sbin/... /usr/sbin/dhcpcd -> /sbin/dhcpcd /usr/sbin/ip -> /sbin/ip When are these supposed to go away or completely moved to /usr/? -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
Christian Hesse <list@eworm.de> on Thu, 2012/07/26 12:46:
Christian Hesse <list@eworm.de> on Thu, 2012/07/26 10:27:
Rodrigo Rivas <rodrigorivascosta@gmail.com> on Thu, 2012/07/26 10:18:
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik <jayesh.badwaik90@gmail.com>wrote:
Why will /opt have to go?
Well, then:
/opt -> /usr/opt
And everyone will be happy :)
BTW, will there be the move from /bin to /usr/bin in the foreseeable future?
Good question. I can not remember having seen and recent plans on it.
This gives an idea about which packages still have files in /bin/:
$ pacman -Qoq /bin/* | sort | uniq
And the same for /sbin/:
$ pacman -Qoq /sbin/* | sort | uniq
No single file that does not belong to a package here... Good conditions for a smooth update. ;)
That said i still have two files linked from /usr/sbin/ to /sbin/...
/usr/sbin/dhcpcd -> /sbin/dhcpcd /usr/sbin/ip -> /sbin/ip
When are these supposed to go away or completely moved to /usr/?
I was wrong, there are some more: /bin/ping6 -> /usr/bin/ping6 /bin/awk -> gawk /bin/gawk -> /usr/bin/gawk /bin/ping -> /usr/bin/ping /bin/hostname -> /usr/bin/hostname -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
Well, then:
/opt -> /usr/opt
And everyone will be happy :)
No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict. -- Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On Thu, Jul 26, 2012 at 10:48 AM, Jayesh Badwaik <jayesh.badwaik90@gmail.com
wrote:
Well, then:
/opt -> /usr/opt
And everyone will be happy :)
No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict.
But then, /usr/local is for system administrator stuff, so what about? /opt -> /usr/local/opt /usr/local -> /local Just half kidding!
Op 26 jul. 2012 10:56 schreef "Rodrigo Rivas" <rodrigorivascosta@gmail.com> het volgende:
On Thu, Jul 26, 2012 at 10:48 AM, Jayesh Badwaik <
jayesh.badwaik90@gmail.com
wrote:
Well, then:
/opt -> /usr/opt
And everyone will be happy :)
No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict.
But then, /usr/local is for system administrator stuff, so what about?
close, but no cookie. /usr/local is for locally compiled stuff where no packages are used (sysadmin!). Also, these should adhere to the Unix standards for file locations (binaries, libraries, config, etc) /opt is for third-party stuff like closed-source software. The idea is to let each such application have it's own hierarchie without cluttering the rest of the system. mvg, Guus
On Thursday, July 26, 2012 10:56:37 AM Rodrigo Rivas wrote:
On Thu, Jul 26, 2012 at 10:48 AM, Jayesh Badwaik <jayesh.badwaik90@gmail.com
wrote:
Well, then: /opt -> /usr/opt
And everyone will be happy :)
No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict.
But then, /usr/local is for system administrator stuff, so what about?
/opt -> /usr/local/opt /usr/local -> /local
Just half kidding!
Well then /usr/lib -> /lib /usr/lib64 -> /lib64 /usr/bin ->/bin /usr/local/opt /opt That should do it ;)
On Thu, 2012-07-26 at 14:18 +0530, Jayesh Badwaik wrote:
Well, then:
/opt -> /usr/opt
And everyone will be happy :)
No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict.
I need to go back to the future, sorry, back to the past /media/maverick/usr/local/bin ... "Personal" stuff was in /usr/local ;). Special stuff still is in /opt, e.g. /media/avlinux/opt/Ardour-3.0beta1a_10644-dbg Pff ;) ... :p Ralf
On Thursday 26 Jul 2012 11:12:34 Ralf Mardorf wrote:
On Thu, 2012-07-26 at 14:18 +0530, Jayesh Badwaik wrote:
Well, then: /opt -> /usr/opt
And everyone will be happy :)
No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict.
I need to go back to the future, sorry, back to the past
/media/maverick/usr/local/bin ...
"Personal" stuff was in /usr/local ;).
Special stuff still is in /opt, e.g. /media/avlinux/opt/Ardour-3.0beta1a_10644-dbg
Pff ;) ... :p Ralf
Ohh right, dear me. By personal ofcourse, I meant, special to the user of the computer. Not personal files. Not a good time for me writing mails I guess. I already made more errors elsewhere, readying myself for a barraged flame now! -- Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Thu, 2012-07-26 at 14:18 +0530, Jayesh Badwaik wrote:
Well, then:
/opt -> /usr/opt
And everyone will be happy :)
No, I guess not, /usr is for vendor-supplied stuff. /opt is for personal stuff. That is the conflict.
I need to go back to the future, sorry, back to the past
/media/maverick/usr/local/bin ...
"Personal" stuff was in /usr/local ;).
/usr/local was abandoned in 1987 already..... In former times all non-admin binaries have ben in /bin. Then /usr/bin was created (world writable) for personal binaries of general interest. Steve Bourne soon discovered that these binaries have been of low quality and wrote a cron script that checked each day whether the documentation was as recent as the binaries and otherwise removed the new binaries. This is why we have usable documentaion on UNIX. Later /usr/bin was hijacked by the system and people created /usr/local..... In 1987, all UNIX vendors decided that /usr/local is not useful as it causes more problems (from e.g. name space clashes) than it solves and /usr/local was abbandoned in favor of /opt/<packet>/bin. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Why will /opt have to go?
I think he meant it will have to leave root. It should have been under /usr like /usr/local in the first place. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik <jayesh.badwaik90@gmail.com> wrote:
Why will /opt have to go?
I don't think we will ever manage to get rid of /opt. However, if we were to follow brainworker's renaming scheme I'd suggest /opt to /crap Should make it clear what kind of packages belong there ;-) -t
On Thursday 26 Jul 2012 12:50:47 Tom Gundersen wrote:
I don't think we will ever manage to get rid of /opt. However, if we were to follow brainworker's renaming scheme I'd suggest
/opt to /crap
Should make it clear what kind of packages belong there ;-)
;-) -- Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On Thursday, July 26, 2012 12:50:47 PM Tom Gundersen wrote:
On Thu, Jul 26, 2012 at 8:53 AM, Jayesh Badwaik
<jayesh.badwaik90@gmail.com> wrote:
Why will /opt have to go?
I don't think we will ever manage to get rid of /opt. However, if we were to follow brainworker's renaming scheme I'd suggest
/opt to /crap
Should make it clear what kind of packages belong there ;-)
-t
Hey now we are making progress
» The merged directory /usr, containing almost the entire vendor-supplied operating system resources, offers us a number of new features regarding OS snapshotting and options for enterprise environments for network sharing or running multiple guests on one host. Most of this is much harder to accomplish, or even impossible, with the current arbitrary split of tools across multiple directories.
With all vendor-supplied OS resources in a single directory /usr they may be shared atomically, snapshots of them become atomic, and the file system may be made read-only as a single unit. «
hmmm, I think I've brought this up before and forgotten the response, something along the lines of they are not static anymore anyway. They are atleast majoratively on OpenBSD. I believe /bin, /sbin aka the root, etc. traditionally contained static binaries so you would have a highly reliable working core system with just say a 50 Mb / partition that you could easily hack and restore and rarely remount for example. I welcome the read-only root though and I haven't looked and forget some of the complexities at play. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________
Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
hmmm, I think I've brought this up before and forgotten the response, something along the lines of they are not static anymore anyway. They are atleast majoratively on OpenBSD.
*BSD ignored most FHS agreements from 1987 and unfortunately Linux followed this.
I believe /bin, /sbin aka the root, etc. traditionally contained static binaries so you would have a highly reliable working core system with just say a 50 Mb / partition that you could easily hack and restore and rarely remount for example.
See my recent post for the real historical background. /sbin was created for SunOS-4.0 for the few (at that time static) binaries that are needed in order to bootstrap the multi-user mode. At the same time, /usr/etc was renamed to /usr/sbin.
I welcome the read-only root though and I haven't looked and forget some of the complexities at play.
There have been some other changes before 1987, that allowed to have /usr read-only - as required by the berkely "nd" driver that introduced the ability to boot diskless clients. These changes however have been introduced as a hack and many symlinks have been introduced to work around files that have been on /usr but need to be writable (e.g. /usr/spool). With SunOS-4.0 and the FHS UNIX summit in 1987, /var and /opt have been introduced. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Ian Fleming <itremmons@gmail.com> wrote:
I beleive its a question of
How is the filesytem structure and its distributed nature/capabilities relevant today
i.e the need for /bin or /lib even.
/bin has been removed in 1987 already - in favor of a symlink to /usr/bin and a few programs in the (at that time) newly created /sbin. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Ken CC <ken.ccao@gmail.com> wrote:
On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote:
I laugh away this trouble. Is there any information about the advantages of lib -> usr/lib?
anyone likes to answer this question?
The "advantage" is that you no longer can boot with a small root filesystem and later mount /usr. So this change is a questionable change. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
participants (18)
-
Baho Utot
-
brainworker＠lavabit.com
-
C Anthony Risinger
-
Christian Hesse
-
Damjan
-
Daniel Wallace
-
Guus Snijders
-
Ian Fleming
-
Jayesh Badwaik
-
Joerg.Schilling＠fokus.fraunhofer.de
-
Ken CC
-
Kevin Chadwick
-
Menachem Moystoviz
-
Oon-Ee Ng
-
Ralf Mardorf
-
Rodrigo Rivas
-
Timothy Rice
-
Tom Gundersen