Muromec
29.08.2005, 18:31
В большинстве линукс-дистрибутивах существуют специальные системы управления софтом - в пакетных дистрибутивах этим занимаются пакетные менеджеры, в gentoo и BSD - системы портов.
Из-за этого у линуксоидов другой подход к установке/обновлению софта: вместо наблюдения за сайтами производителей или просмотра разного рода новостей о выходе новых версий продуктов мы используем вышеуказанные средства.
приблизительная схема действия пакетных менеджеров ( ПМ ):
1. мейнтейнер пакета узнает о выходе новой версии, собирает её ( возможно добавляя сторонние патчи, изменяя флаги оптимизации, используя нестандартные опции при конфигурировании или внося другие изменения ), проверяет стабильность программы, упаковывает собранную программу в пакет и добавляет пакет в репозитарий ( специальное хранилище пакетов со списком имеющихся пакетов, их версий, зависимостей и т.д. ).
2. ПМ связывается с сервером репозитария ( это обычный ftp/http/rsync сервер ) и получает список пакетов
3. когда пользователь дает команду "обновить пакет/группу пакетов/все пакеты" ПМ проверяет, является ли версия установленного пакета последней установленной и (необязательно) проверяет версии программ/библиотек, от которых зависит требуемый пакет. и в случае необходимости обновления дает команду установить нужные пакеты.
очень часто это разные программы - одна служит чисто для установки нужного пакета, другая более интеллектуальна - рассчитывает список зависимостей и требующих обновления программ, обрабатывает конфликты разных программ/версий и прочее, после чего передает список первой.
4. когда установщик получает команду на установку/удаление списка программ, он проверяет, имеются ли нужные пакеты на машине и при необходимости загружает (или догружает) недостающие, после чего производит установку (проверяя контрольную сумму пакета, некоторые метаданные и прочее ).
приблизительная схема действия системы портов (на примере gentoo portage ):
1. мейнтейнер пакета узнает о выходе новой версии, собирает её ( возможно добавляя сторонние патчи, изменяя флаги оптимизации, используя нестандартные опции при конфигурировании или внося другие изменения ), проверяет стабильность программы, пишет ebuild (небольшой текстовый файл, в котором описано, где получить архив с исходными текстами, как распаковать, собрать, установить и прочее). к ебилду прилагаются вспомогательные файлы, генерируемые автоматически - digestы и Manifest. digestы содержат размер и контрольные суммы загружаемых файлов ( например архивов с исходниками ) и создаются для каждой версии ебилда, а манифесты содержать то же самое для файлов из папки ебилда (включая digestы).
% ls portage/tree/net-im/psi -R
portage/tree/net-im/psi:
ChangeLog files/ Manifest metadata.xml psi-0.9.3-r1.ebuild psi-0.9.3-r2.ebuild psi-0.9.3-r3.ebuild psi-0.9.3-r4.ebuild
portage/tree/net-im/psi/files:
digest-psi-0.9.3-r1 psi-desktop_file_and_icons_directories.patch psi-reverse_trayicon.patch
digest-psi-0.9.3-r2 psi-desktop.patch psi-status_indicator++_add-on_roster-nr.patch
digest-psi-0.9.3-r3 psi-emergency.png vcard-photo-interface.patch
digest-psi-0.9.3-r4 psi-indicator.png
psi-add-status-history.patch psi-pathfix.patch
% cat portage/tree/net-im/psi/Manifest
MD5 f67fb9545a019937912440c7fcebf9b2 psi-0.9.3-r2.ebuild 9438
MD5 76acc3aba2331ac16bff40358db640d8 psi-0.9.3-r4.ebuild 9127
MD5 0691899c53d869d2909e460646237a98 psi-0.9.3-r1.ebuild 8151
MD5 605af285d446205b316ffa6dceca96a2 psi-0.9.3-r3.ebuild 9836
MD5 74aed80010c87a4b83e1cbcc40bc9319 ChangeLog 10341
MD5 9b91ead14acbf0da98d3b33e75c67e79 metadata.xml 306
MD5 b35105d488f11cae19484290159023b1 files/psi-add-status-history.patch 13703
MD5 fc8fae7a49b592b4f2c2914c21494c11 files/digest-psi-0.9.3-r1 1924
MD5 db2a4c5b68dbb0147392a4657f2dbc92 files/digest-psi-0.9.3-r2 2132
MD5 839e6fa5502e1f03a660918bc30e48b5 files/digest-psi-0.9.3-r3 2211
MD5 55307aeb75ba675468f91832d951eff7 files/digest-psi-0.9.3-r4 1975
MD5 0d5cafd17325fc912c4855252d73378f files/psi-indicator.png 300
MD5 0250867fe42d1dc91e798336869a09d6 files/vcard-photo-interface.patch 32494
MD5 4195bf9d000383fae25545249a3f8709 files/psi-desktop_file_and_icons_directories.patch 1454
MD5 18253b59a4622a06bc3a17a4eef93d22 files/psi-status_indicator++_add-on_roster-nr.patch 9821
MD5 5fa629c5177a7b1c5090428e22b7ec30 files/psi-emergency.png 295
MD5 76f5cc28b75698adddaa068e5f4593f5 files/psi-pathfix.patch 462
MD5 893421922de588e6a40fbe8357976279 files/psi-reverse_trayicon.patch 937
MD5 1c741813b6d820d43475058dbfab3100 files/psi-desktop.patch 492
% cat portage/tree/net-im/psi/files/digest-psi-0.9.3-r4
MD5 d20f3bb530235a246bc2d92308089744 psi-0.9.3.tar.bz2 1423322
MD5 b148793cf8f1f6d93df089263b0b8ccf psi-0.9.3-gentoo-extras-0.5.tar.bz2 105895
MD5 2885ffd0943e95edc0b8521309b01d32 psi_ar-0.9.3.tar.bz2 31466
< вырезаны строки с другими файлами языков >
MD5 6ef95100b9ff08b86f4404f32694d451 psi_zh-0.9.3-a.tar.bz2 31925
после этого мейнтерйнер добавляет ебилд и (в этом не уверен) вспомагательные файлы на сервер с деревом портов.
2. получив команду "обновить дерево портов" emerge запускает rsync для обновления локального дерева портов ( совокупности ебилдов, дайджестов, манифестов, профилей, конфигурационных файлов и прочего добра. всего ~120 тысяч текстовых файлов. в архиве 19 мб, в развернутом состоянии 450 мб). естественно rsync скачивает только новые и изменившиеся файлы.
3. когда пользователь дает команду "обновить пакет/группу пакетов/все пакеты" emerge проверяет, является ли версия установленного пакета последней установленной и (необязательно) проверяет версии программ/библиотек, от которых зависит требуемый пакет. и в случае необходимости обновления дает программе ebuild команду установить нужные пакеты.
4. когда программа ebuild получает команду на установку/удаление списка программ, он проверяет, имеются ли нужные архивы с исходными файлами на машине и при необходимости загружает (или догружает) недостающие, после чего собирает программу согласно правилам в файле ебилда ( реально - файл ебилда является shell-скриптом, использующем функции и переменные из других частей системы portage и содержащий функции src_unpack, src_compile, src_install и подобные, которые и вызываются из программы ebuild )
ЗАМЕЧАНИЕ: поскольку программа и файлы называются одинаково вы можете и запутаться, читая этот текст.
программа ebuild - скрипты на питоне и шелле, которые находятся в /usr/lib/portage/bin/ + симлинки в /usr/bin . это программа типа "установщик".
файл *.ebuild - файл с полным именем $PORTDIR/категория/имя_программы/имя_программы-версия_программы-rверсия_ебилда.ebuild
например /usr/portage/net-im/psi/psi-0.9.3-r3.ebuild ( категория - сеть-мгновенные_сообщения, название - psi, версия программы 0.9.3, версия ебилда - 3 ). как выше написано, тоже является shell-скриптом.
portage - общее имя для всей системы портов - дерево, база данных, сами программы...
emerge - интеллектуальная программа. для установки из исходников запускает ebuild. для установки бинарного пакета нужно использовать emerge -k имя программы. тогда emerge проверит наличие бинарного пакета в $PKGDIR/категория/имя_программы-версия.tbz2 если он есть, он будет установлен (при условии выполнения зависимостей и прочего), если его нет - программа будет собрана через ebuild
если выполнить emerge -K имя программы (большая k), при отсутствии бинарного пакета и бинарных пакетов зависисмостей установка будет прервана ( binary only mode ).
для сборки бинарного пакета после установки собранной программы нужно выполнить emerge -b. для сборки пакета без его установки (например пакета для другой системы) emerge -B
рекомендую добавить в автозагрузку Вашего shell (например в /etc/profile ) alias emerge="emerge -bk"
тогда при вводе команды emerge psi будет выполнена emerge -bk psi
обновление дерева портов - emerge --sync
удаление программы emerge -C имя_программы
emerge -uD "глубокое обновление" обновится не только сама программа, но и зависимости (если необходимо)
emerge -p emerge напечатает таблицу пакетов, которые он собирается установить (включая зависимости) установка произведена не будет
-pv - кроме имен и версий будут напечатаны размеры недостающих пакетов и use - флаги
emerge -f будут проверены контрольные суммы необходимых пакетов ( включая зависисмости ). отсутствующие файлы будут загружены, недогруженные - догружены. установка произведена не будет.
пример:
emerge --sync && emerge -uDf kde && emerge -uD kde
сначала будет обновлено дерево портов, потом emerge скачает все пакеты, нужные для сборки kde, потом соберет kde.
если сделать просто emerge --sync && emerge -uD kde, пакет будет загружаться непосредственно перед сборкой
если запустить emerge --sync && emerge -uDf kde & emerge -uD kde
( один & ) загрузка и сборка будут идти параллельно ( если файл еще будет скачиваться, emerge -uD подождет emerge`а --uDf )
World и system
предопределенный класс system содержит перечисленные в профиле пакеты. для обновления всех базовых пакетов системы достаточно выполнить
emerge -uD system
класс world содержит все пакеты класса system + пакеты, которые установил пользователь.
ЗАМЕЧАНИЕ в класс world добавляются только явно запрошенные программы. пример: я хочу установить Программу-2.4. для её работы необходима Библиотека-1.3
после вызова emerge -bk Программа
будут установлены оба пакета ( П и Б ). если бинарные пакеты есть и лежат в нужном месте, будут установлены они. после установки каждого пакета будет собран бинарный пакет.
НО пакет Библиотека-1.3 НЕ будет занесен в класс world
для получения дополнительно информации прочитайте man emerge, man portage, man ebuild.
Стабильные и нестабильные пакеты.
на многих системах emerge --sync и emerge -uDp world выполняется автоматически по крону ( планировщик задач ). поэтому нужно предотвратить установку неоттестированных пакетов. пакеты содержат поле KEYWORDS в которое записывается на каких архитектурах пакет может работать, на каких он работает недостаточно стабильно ( с точки зрения мейнтейнера ). например
KEYWORDS="~alpha amd64 hppa ia64 ~mips ppc sparc x86"
символом "~" отмечены проблемные архитектуры
если задать переменную окружения ACCEPT_KEYWORDS равной ~x86, пакеты с таким кейвордом можно будет установить. в терминологии Gentoo это называется "MASKED PACKAGES". обычно последние версии программ имеют именно этот кейворд. при этом по запросу на установку это программы будет установлена последняя версия с разрешенными кейвордами и сообщений об ошибке не будет
также можно разрешать установку отдельных "замаскированных" пакетов. файл /etc/portage/package.unmask
=media-sound/amarok-1.3_beta*
=net-im/jabberd-2*
разрешает установку бета версий амарока и второй ветки сервера jabberd даже если они замаскированы. также пакет может блокироваться по "missing keyword" - значит ваша архитектура не поддерживается или из файла package.mask в профиле (/usr/portage/profiles/package.mask). файлы в /etc/portage имеют более высокий приоритет. также можно заблокировать установку новых версий определенных программ:
файл /etc/portage/package.mask
>media-video/nvidia-kernel-1.0.6629-r4
>media-video/nvidia-glx-1.0.6629-r6
модуль ядра nvidia и сопутствующая библиотека GL версий выше 1.0.6629-r4 и 1.0.6629-r6 не будут устанавливаться.
Deltup
Новая версия kde (все кроме локализаций) занимает 160 мб. у многих дос сих пор dialup, у многих платный трафик. приходится себя ограничивать )-: deltup - система бинарных патчей позволяет скачать только 20 мб и получить тот же эффект (требуется предыдущая версия этих пакетов).
по ссылке описано, как заставить gentoo автоматически пользоваться этой возможностью http://ru.gentoo-wiki.com/HOWTO_Экономия_трафика_с_помощью_deltup
Битые файлы
Случай из жизни:
захотел попробовать kde 3.5 alpha. пошел скачивать Live CD ( 350 мб ).
скачал. нарезал. попробовал загрузить - полезли segfaultы...
проверил контрольную сумму - не совпала )-:
через какое-то время пришла в голову идея: попробовать вылечить файл - скачать только те фрагменты файла, которые у меня ошибочные, а потом cat, head, tail и заменить. как вычислить неверные участки я не придумал ( кроме как посчитать md5 разных фрагментов ). потом догадался взять bittorrent. начал качать такой же файл, а потом заменил. далее сказал mldonkey, чтобы тот "проверил части" отделался семью метрами. проверил md5 еще раз - совпало (-:
Из-за этого у линуксоидов другой подход к установке/обновлению софта: вместо наблюдения за сайтами производителей или просмотра разного рода новостей о выходе новых версий продуктов мы используем вышеуказанные средства.
приблизительная схема действия пакетных менеджеров ( ПМ ):
1. мейнтейнер пакета узнает о выходе новой версии, собирает её ( возможно добавляя сторонние патчи, изменяя флаги оптимизации, используя нестандартные опции при конфигурировании или внося другие изменения ), проверяет стабильность программы, упаковывает собранную программу в пакет и добавляет пакет в репозитарий ( специальное хранилище пакетов со списком имеющихся пакетов, их версий, зависимостей и т.д. ).
2. ПМ связывается с сервером репозитария ( это обычный ftp/http/rsync сервер ) и получает список пакетов
3. когда пользователь дает команду "обновить пакет/группу пакетов/все пакеты" ПМ проверяет, является ли версия установленного пакета последней установленной и (необязательно) проверяет версии программ/библиотек, от которых зависит требуемый пакет. и в случае необходимости обновления дает команду установить нужные пакеты.
очень часто это разные программы - одна служит чисто для установки нужного пакета, другая более интеллектуальна - рассчитывает список зависимостей и требующих обновления программ, обрабатывает конфликты разных программ/версий и прочее, после чего передает список первой.
4. когда установщик получает команду на установку/удаление списка программ, он проверяет, имеются ли нужные пакеты на машине и при необходимости загружает (или догружает) недостающие, после чего производит установку (проверяя контрольную сумму пакета, некоторые метаданные и прочее ).
приблизительная схема действия системы портов (на примере gentoo portage ):
1. мейнтейнер пакета узнает о выходе новой версии, собирает её ( возможно добавляя сторонние патчи, изменяя флаги оптимизации, используя нестандартные опции при конфигурировании или внося другие изменения ), проверяет стабильность программы, пишет ebuild (небольшой текстовый файл, в котором описано, где получить архив с исходными текстами, как распаковать, собрать, установить и прочее). к ебилду прилагаются вспомогательные файлы, генерируемые автоматически - digestы и Manifest. digestы содержат размер и контрольные суммы загружаемых файлов ( например архивов с исходниками ) и создаются для каждой версии ебилда, а манифесты содержать то же самое для файлов из папки ебилда (включая digestы).
% ls portage/tree/net-im/psi -R
portage/tree/net-im/psi:
ChangeLog files/ Manifest metadata.xml psi-0.9.3-r1.ebuild psi-0.9.3-r2.ebuild psi-0.9.3-r3.ebuild psi-0.9.3-r4.ebuild
portage/tree/net-im/psi/files:
digest-psi-0.9.3-r1 psi-desktop_file_and_icons_directories.patch psi-reverse_trayicon.patch
digest-psi-0.9.3-r2 psi-desktop.patch psi-status_indicator++_add-on_roster-nr.patch
digest-psi-0.9.3-r3 psi-emergency.png vcard-photo-interface.patch
digest-psi-0.9.3-r4 psi-indicator.png
psi-add-status-history.patch psi-pathfix.patch
% cat portage/tree/net-im/psi/Manifest
MD5 f67fb9545a019937912440c7fcebf9b2 psi-0.9.3-r2.ebuild 9438
MD5 76acc3aba2331ac16bff40358db640d8 psi-0.9.3-r4.ebuild 9127
MD5 0691899c53d869d2909e460646237a98 psi-0.9.3-r1.ebuild 8151
MD5 605af285d446205b316ffa6dceca96a2 psi-0.9.3-r3.ebuild 9836
MD5 74aed80010c87a4b83e1cbcc40bc9319 ChangeLog 10341
MD5 9b91ead14acbf0da98d3b33e75c67e79 metadata.xml 306
MD5 b35105d488f11cae19484290159023b1 files/psi-add-status-history.patch 13703
MD5 fc8fae7a49b592b4f2c2914c21494c11 files/digest-psi-0.9.3-r1 1924
MD5 db2a4c5b68dbb0147392a4657f2dbc92 files/digest-psi-0.9.3-r2 2132
MD5 839e6fa5502e1f03a660918bc30e48b5 files/digest-psi-0.9.3-r3 2211
MD5 55307aeb75ba675468f91832d951eff7 files/digest-psi-0.9.3-r4 1975
MD5 0d5cafd17325fc912c4855252d73378f files/psi-indicator.png 300
MD5 0250867fe42d1dc91e798336869a09d6 files/vcard-photo-interface.patch 32494
MD5 4195bf9d000383fae25545249a3f8709 files/psi-desktop_file_and_icons_directories.patch 1454
MD5 18253b59a4622a06bc3a17a4eef93d22 files/psi-status_indicator++_add-on_roster-nr.patch 9821
MD5 5fa629c5177a7b1c5090428e22b7ec30 files/psi-emergency.png 295
MD5 76f5cc28b75698adddaa068e5f4593f5 files/psi-pathfix.patch 462
MD5 893421922de588e6a40fbe8357976279 files/psi-reverse_trayicon.patch 937
MD5 1c741813b6d820d43475058dbfab3100 files/psi-desktop.patch 492
% cat portage/tree/net-im/psi/files/digest-psi-0.9.3-r4
MD5 d20f3bb530235a246bc2d92308089744 psi-0.9.3.tar.bz2 1423322
MD5 b148793cf8f1f6d93df089263b0b8ccf psi-0.9.3-gentoo-extras-0.5.tar.bz2 105895
MD5 2885ffd0943e95edc0b8521309b01d32 psi_ar-0.9.3.tar.bz2 31466
< вырезаны строки с другими файлами языков >
MD5 6ef95100b9ff08b86f4404f32694d451 psi_zh-0.9.3-a.tar.bz2 31925
после этого мейнтерйнер добавляет ебилд и (в этом не уверен) вспомагательные файлы на сервер с деревом портов.
2. получив команду "обновить дерево портов" emerge запускает rsync для обновления локального дерева портов ( совокупности ебилдов, дайджестов, манифестов, профилей, конфигурационных файлов и прочего добра. всего ~120 тысяч текстовых файлов. в архиве 19 мб, в развернутом состоянии 450 мб). естественно rsync скачивает только новые и изменившиеся файлы.
3. когда пользователь дает команду "обновить пакет/группу пакетов/все пакеты" emerge проверяет, является ли версия установленного пакета последней установленной и (необязательно) проверяет версии программ/библиотек, от которых зависит требуемый пакет. и в случае необходимости обновления дает программе ebuild команду установить нужные пакеты.
4. когда программа ebuild получает команду на установку/удаление списка программ, он проверяет, имеются ли нужные архивы с исходными файлами на машине и при необходимости загружает (или догружает) недостающие, после чего собирает программу согласно правилам в файле ебилда ( реально - файл ебилда является shell-скриптом, использующем функции и переменные из других частей системы portage и содержащий функции src_unpack, src_compile, src_install и подобные, которые и вызываются из программы ebuild )
ЗАМЕЧАНИЕ: поскольку программа и файлы называются одинаково вы можете и запутаться, читая этот текст.
программа ebuild - скрипты на питоне и шелле, которые находятся в /usr/lib/portage/bin/ + симлинки в /usr/bin . это программа типа "установщик".
файл *.ebuild - файл с полным именем $PORTDIR/категория/имя_программы/имя_программы-версия_программы-rверсия_ебилда.ebuild
например /usr/portage/net-im/psi/psi-0.9.3-r3.ebuild ( категория - сеть-мгновенные_сообщения, название - psi, версия программы 0.9.3, версия ебилда - 3 ). как выше написано, тоже является shell-скриптом.
portage - общее имя для всей системы портов - дерево, база данных, сами программы...
emerge - интеллектуальная программа. для установки из исходников запускает ebuild. для установки бинарного пакета нужно использовать emerge -k имя программы. тогда emerge проверит наличие бинарного пакета в $PKGDIR/категория/имя_программы-версия.tbz2 если он есть, он будет установлен (при условии выполнения зависимостей и прочего), если его нет - программа будет собрана через ebuild
если выполнить emerge -K имя программы (большая k), при отсутствии бинарного пакета и бинарных пакетов зависисмостей установка будет прервана ( binary only mode ).
для сборки бинарного пакета после установки собранной программы нужно выполнить emerge -b. для сборки пакета без его установки (например пакета для другой системы) emerge -B
рекомендую добавить в автозагрузку Вашего shell (например в /etc/profile ) alias emerge="emerge -bk"
тогда при вводе команды emerge psi будет выполнена emerge -bk psi
обновление дерева портов - emerge --sync
удаление программы emerge -C имя_программы
emerge -uD "глубокое обновление" обновится не только сама программа, но и зависимости (если необходимо)
emerge -p emerge напечатает таблицу пакетов, которые он собирается установить (включая зависимости) установка произведена не будет
-pv - кроме имен и версий будут напечатаны размеры недостающих пакетов и use - флаги
emerge -f будут проверены контрольные суммы необходимых пакетов ( включая зависисмости ). отсутствующие файлы будут загружены, недогруженные - догружены. установка произведена не будет.
пример:
emerge --sync && emerge -uDf kde && emerge -uD kde
сначала будет обновлено дерево портов, потом emerge скачает все пакеты, нужные для сборки kde, потом соберет kde.
если сделать просто emerge --sync && emerge -uD kde, пакет будет загружаться непосредственно перед сборкой
если запустить emerge --sync && emerge -uDf kde & emerge -uD kde
( один & ) загрузка и сборка будут идти параллельно ( если файл еще будет скачиваться, emerge -uD подождет emerge`а --uDf )
World и system
предопределенный класс system содержит перечисленные в профиле пакеты. для обновления всех базовых пакетов системы достаточно выполнить
emerge -uD system
класс world содержит все пакеты класса system + пакеты, которые установил пользователь.
ЗАМЕЧАНИЕ в класс world добавляются только явно запрошенные программы. пример: я хочу установить Программу-2.4. для её работы необходима Библиотека-1.3
после вызова emerge -bk Программа
будут установлены оба пакета ( П и Б ). если бинарные пакеты есть и лежат в нужном месте, будут установлены они. после установки каждого пакета будет собран бинарный пакет.
НО пакет Библиотека-1.3 НЕ будет занесен в класс world
для получения дополнительно информации прочитайте man emerge, man portage, man ebuild.
Стабильные и нестабильные пакеты.
на многих системах emerge --sync и emerge -uDp world выполняется автоматически по крону ( планировщик задач ). поэтому нужно предотвратить установку неоттестированных пакетов. пакеты содержат поле KEYWORDS в которое записывается на каких архитектурах пакет может работать, на каких он работает недостаточно стабильно ( с точки зрения мейнтейнера ). например
KEYWORDS="~alpha amd64 hppa ia64 ~mips ppc sparc x86"
символом "~" отмечены проблемные архитектуры
если задать переменную окружения ACCEPT_KEYWORDS равной ~x86, пакеты с таким кейвордом можно будет установить. в терминологии Gentoo это называется "MASKED PACKAGES". обычно последние версии программ имеют именно этот кейворд. при этом по запросу на установку это программы будет установлена последняя версия с разрешенными кейвордами и сообщений об ошибке не будет
также можно разрешать установку отдельных "замаскированных" пакетов. файл /etc/portage/package.unmask
=media-sound/amarok-1.3_beta*
=net-im/jabberd-2*
разрешает установку бета версий амарока и второй ветки сервера jabberd даже если они замаскированы. также пакет может блокироваться по "missing keyword" - значит ваша архитектура не поддерживается или из файла package.mask в профиле (/usr/portage/profiles/package.mask). файлы в /etc/portage имеют более высокий приоритет. также можно заблокировать установку новых версий определенных программ:
файл /etc/portage/package.mask
>media-video/nvidia-kernel-1.0.6629-r4
>media-video/nvidia-glx-1.0.6629-r6
модуль ядра nvidia и сопутствующая библиотека GL версий выше 1.0.6629-r4 и 1.0.6629-r6 не будут устанавливаться.
Deltup
Новая версия kde (все кроме локализаций) занимает 160 мб. у многих дос сих пор dialup, у многих платный трафик. приходится себя ограничивать )-: deltup - система бинарных патчей позволяет скачать только 20 мб и получить тот же эффект (требуется предыдущая версия этих пакетов).
по ссылке описано, как заставить gentoo автоматически пользоваться этой возможностью http://ru.gentoo-wiki.com/HOWTO_Экономия_трафика_с_помощью_deltup
Битые файлы
Случай из жизни:
захотел попробовать kde 3.5 alpha. пошел скачивать Live CD ( 350 мб ).
скачал. нарезал. попробовал загрузить - полезли segfaultы...
проверил контрольную сумму - не совпала )-:
через какое-то время пришла в голову идея: попробовать вылечить файл - скачать только те фрагменты файла, которые у меня ошибочные, а потом cat, head, tail и заменить. как вычислить неверные участки я не придумал ( кроме как посчитать md5 разных фрагментов ). потом догадался взять bittorrent. начал качать такой же файл, а потом заменил. далее сказал mldonkey, чтобы тот "проверил части" отделался семью метрами. проверил md5 еще раз - совпало (-: