Ну, насколько я понимаю, в NixOS это разруливается примерно так: при установке любой программы создаётся отдельный каталог (что-то вроде /nix/store/<название каталога>). Название каталога состоит из UUID и названия программы (в NixOS UUID почему-то идёт в начале названия каталога, что затрудняет ручное хождение по этим каталогам: упорядочиваются они из-за этого не по алфавиту). Каждая программа (более того, каждая отдельная версия) устанавливается в свой каталог. Внутри каталога, естественно, своя иерархия каталогов /bin, /lib, и.т.д.

$PATH — с помощью символических ссылок и аналога eselect.
$LD_PRELOAD разруливать не нужно, так как эта переменная управляет загрузкой библиотеки _перед_ запуском программы. Этот механизм использует, например, программа leaktracer для обнаружения утечек памяти и другие программы, которым нужно подменить библиотечные вызовы. Разруливать нужно $LD_LIBRARY_PATH. Про это надо будет изучить более подробно. Её вроде как нужно разруливать и на этапе компиляции, и на этапе выполнения (хотя я не уверен, что и то и другое одновременно.) /etc/ld.so.conf, понятно, использовать нельзя, так как тогда все программы полезут в один каталог за библиотеками, что не соответствует поставленной задаче.

Можно поподробнее про @preserved-rebuild? Что он собой представляет и каков механизм его работы?

Думаю, да. Исполняемый файл opera — это симлинк на один из трёх opera-$версия.

А я довольно часто трогал LD_LIBRARY_PATH, чтобы запустить скачанную «на посмотреть» программу с библиотеками из домашнего каталога.

Собственно, происходит именно так, как в portage 2.2: библиотека удаляется только когда ни одна программа от неё не зависит.

Я думаю, не совсем так. glib — это ведь библиотека, насколько я понимаю, поэтому на неё не нужно «переключаться».  Обновляется библиотека, потом проверяется, какие пакеты зависят от старой версии, затем они пересобираются для работы с новой версией (в новые слоты, то есть какое-то время программа одной версии есть в двух экземплярах — с использованием старой и новой версии), система переключается на новый профиль. Если в течение определённого времени не было замечено проблем в новой версии, старые удаляются, иначе производится откат к старой версии программ/библиотек.
Меня больше интересует вот, что. Можно ли собрать программу так, чтобы она не была привязана к конкретной версии библиотеки, а только к местоположению. То есть, чтобы эти библиотеки можно было именно «переключить»?

Добавлено 12-01-2012 15:57:56
Да, это я, разумеется, писал про то, как я предполагаю это сделать в LFS. В NixOS это может быть сделано иначе — точно я не знаю.

Отредактировано X Strange (12-01-2012 15:57:56)

Такой вопрос.
Когда-то давно, задолго до того как я появился на этом форуме, здесь обсуждалось, что в Windows при безопасном извлечении флэшки происходит не только отмонтирование, но и отключение устройства: лампочка на флэшке обычно гаснет и вроде как опять подмонтировать флэшку уже нельзя — только вытащить из USB-порта и вставить снова. Не помню точно, отображается ли она после этого в диспетчере устройств. В Linux же происходит только отмонтирование. Лампочка не гаснет и можно снова подмонтировать, устройство присутствует в файловой системе /dev. Обычно этого достаточно. Если файловая система отмонтирована, то с файловой системой ничего не должно случиться. Если же на флэшку ничего не записывали, а только читали, то можно выдёргивать без отмонтирования.  А как быть с командой mkfs, которая пишет на флэшку в обход файловой системы, когда ни о какой файловой системе или монтировании речи не идёт? Как обеспечивается целостность данных?

А как это сделать стандартными виндовыми средствами?
Можно ли через USR подключить флэшку, отмонтированную стандартными виндовыми средствами?

Это от флешки зависит. Вполне могут сдохнуть, поэтому Винь подстраховывается, но реакция у флешек разная.

В Диспетчере Устройств можно Поиск запустить и некоторые флешки ответят.

можно командой eject.

sudo eject /dev/sdX

в качестве X Вставить нужную букву - что пишет?

Это правильно

А вот это не факт. Вобще должно соответствующее устройство в /dev исчезнуть, и появиться сообщение об этом в выводе dmesg. Есть там что-нибудь новое после этого?

И даже лампочка на флешке гаснет?

У меня когда телефон в режиме флешки подключаешь к компу, а потом в гноме нажимаешь "Извлечь устройство", то телефон понимает, что его отключили и выключает режим флешки. А вот в KDE ситуация другая, извлечения телефон не видит и никак на него не реагирует, так и остаётся в режиме флешки пока кабель от компа не отключишь.

Лучше вот так:

(утянуто)

Недавно я обнаружил интересное явление. В последнее время я ставлю виндовые игрушки под wine, а не под windows. Это удобнее по многим причинам, в частности можно отметить возможность оконного запуска и быстрого переключения. Большая часть игрушек, которые я ставил,  работает под wine отлично. Иногда случается так, что игрушка требует наличия вставленного cdrom. В этом случае я создавал iso образ и давал команду:

mount -o loop /path/to/image.iso /mnt/cdrom

и указывал /mnt/cdrom в качестве cd-привода в настройках winecfg. И это работало. Но одна из игрушек так работать не захотела, жалуясь на отсутствие cdrom'a. При этом после того, как я вставил и подмонтировал настоящий cdrom, игрушка запустилась! Я бы понял, если бы это было под виндой! Но под Wine... Видимо, в Wine API есть функция, позволяющая проверить содержимое настоящего CD-привода. Я откопал специальную программу cdemu (http://cdemu.sourceforge.net/), которая с помощью специального модуля ядра (vhba-module) создаёт в каталоге /dev/ виртуальный cd-rom /dev/cdrom1, который потом нужно подмонтировать. С такой эмуляцией всё работает нормально, что, видимо, подтверждает предположение о наличии соотвествующей API-функции.
А теперь вопрос.
В gentoo мне удалось заставить cdemu работать, так как ядро я собирал сам. А вот в ArchLinux возникла проблема с загрузкой модуля, которую мне пока не удалось решить. Можно ли как-нибудь обойтись без cdemu и модулей ядра? Или проще будет собрать ядро вручную и в ArchLinux?

Отредактировано X Strange (04-03-2012 23:56:23)