Чистка системы (Производите чистку?)

[serzh-z]

Вчера начал делать "emerge --depclean" - потом, уже во время удаления пакета gmp, прервал... При последующем запуске обнаружил, что emerge не хочет удалять симлинки по причине "mtime differs". То ли это так и было, то ли часть этих симлинков была в stage3 и имела неверное время. Не суть важно...

В общем, снова пришел к диллеме "чистить или не чистить". Так как просто не терплю наличия в системе файлов неизвестно кому принадлежащих (ну /etc еще, в принципе, можно было бы исключить из этого списка) - это то от чего я так долго некогда пытался убежать.

Так вот подумал - меня одного беспокоит эта параноидальная проблема мусора и философия относительно неё? Кто-нибудь использует всякие неофициальные скрипты cruft и т.д.? Скажем, до сих пор не понимаю чей файл /usr/bin/gcc32...

[TuLiss]

Так вот подумал - меня одного беспокоит эта параноидальная проблема мусора и философия относительно неё?

я подминал тему с таким вопросом, значит ты уже не один =)

[serzh-z]

значит ты уже не один =)

↑

Любопытно - в других дистрах. каждый установленный файл (даже файл базовой системы) принадлежит официально какому-нибудь пакеты или же есть аналогичные с виду "бесхозные" файлы (под руками нет другого линукса, кроме виндовс, что посмотреть самому)?

[(asper]

Я думал , что в Женьке каждый файл имеет своего хозяина и свято верил в это , что то не так ?

[serzh-z]

и свято верил в это

↑

Вот и я свято верил. Но qfile говорит обратное.

[(asper]

equery b /usr/bin/gcc32
[ Searching for file(s) /usr/bin/gcc32 in *... ]

и пусто, тоже самое

[ArtSh]

Перед чисткой, я обычно смотрю что будет происходить

Файлы gcc32 gcc64 судя по всему создаёт какая-то утилита, после установки gcc, (дата изменения соответствует дате последней установки). Может быть это делает gcc-config...

Если файлы создаются после установки, то ни один пакетный менеджер не может установить их принадлежность: что в gentoo, что в других дистрибутивах. Конечно, наличие таких файлов свидететльствует о недоработках...

[alexander30]

значит ты уже не один =)

↑

Любопытно - в других дистрах. каждый установленный файл (даже файл базовой системы) принадлежит официально какому-нибудь пакеты или же есть аналогичные с виду "бесхозные" файлы (под руками нет другого линукса, кроме виндовс, что посмотреть самому)?

В RPM-based дистрах каждый установленный файл принадлежит какому-нибудь пакету (можно просмотреть командой rpm -qf /путь/имя_файла). Однако есть тенденция после удаления/обновления пакета оставлять нетронутыми конфиги, что иногда приводит к нехорошим результатам.

[nonr]

Так вот подумал - меня одного беспокоит эта параноидальная проблема мусора и философия относительно неё? Кто-нибудь использует всякие неофициальные скрипты cruft и т.д.? Скажем, до сих пор не понимаю чей файл /usr/bin/gcc32...

Забей, делай дело, эпизодически сливай свои настройки и важные куски
/etc.
Еще помогает личный HOWTO по установке и перенастройке дистра
с конспективным изложением порядка действий.

usr/bin/gcc32 - скорее всего какой-то сим- или хардлинк gcc на 32 битный
пускач от gcc. Когда установочные скрипты чего-то сздают, оно не
всегда в базу принадлежности по пакетам попадает.

Короче, чистотой особо страдать смысла нет. Полность сконфигуреный
UNIX - это фикция. Припрет - переставишь, используешь при этом
личный HOW-TO для ускорения.

[Mellon]

Тотальную чистку производим раз в полгода.
Раз в три месяца прочесываем сисиему с помощью dep из app-portage/udept.
Раз в неделю проверяем на вшивость (целостность файлов).

[(asper]

Тотальную чистку производим раз в полгода.
Раз в три месяца прочесываем сисиему с помощью dep из app-portage/udept.
Раз в неделю проверяем на вшивость (целостность файлов).

Звучит не плохо , а теперь в примерах Плиз

[Terekhin Alexey]

Дам примеры бы не помешали.

[(asper]

Дам примеры бы не помешали.

И занести это дело в FAQ было бы полезно

[_YT_]

Mellon,

Наверно речь идет о проверке с помощью revdep-rebuild, анализе зависимостей с помощью dep. А что имеешь ввиду под тотальной чисткой?

У примерно 1 раз в месяц полностью архивирую систему моим скриптиком и записываю на болванку, размер примерно одинаковый уже МНОГО месяцев.

[serzh-z]

usr/bin/gcc32 - скорее всего какой-то сим- или хардлинк gcc на 32 битный
пускач от gcc. Когда установочные скрипты чего-то сздают, оно не
всегда в базу принадлежности по пакетам попадает.

↑

Это и так понятно, для чего он служит. Непонятно было, кто его создал и почему он никому не принадлежит. Выясняется, что gcc-config его сделал.

Кстати, есть старый и простой пакет symlinks, который может выявить тучу битых и рекурсивных симлинков (в моем случае после обновления старой версии openldap, сразу же после установки системы - левых симлинков осталась просто куча).

[Mellon]

Хм, ну гента не винда, чтоб за ней следить как за вражеским агентом.
И потом, всё этозависит от уровня вашей паранои
В общем, ничего особенного.
"Тотальная" чистка у меня отличается от сезонной (три месяца):
во первых добавлением проверки мусора скриптом findcruft (с gentoo.org);
во вторых прочесыванием системы согласно хэндбуку File Permissions
Как правило, ничего подозрительного не находится.

Сезонная, базовая чистка включает в себя проверку устаревших зависимостей с помощью как emerge [--deep] --depclean так и с помощью выше упомянутого скрипта dep, кстати, этот же скрипт может вычищать списки /etc/portage/* и /var/lib/portage/world. Также, в это же время, имеет смысл почистить дистфайлы скриптом eclean (app-portage/gentoolkit)

Проверку на вшивость можно возложить на AIDE и сотоварищей из раздела Intrusion Detection
Также может быть полезна следующая команда:

Код: Выделить всё

find /var/db/pkg/ -type d |sed s/"\/var\/db\/pkg\/"//g | grep \/ | sed s/"-[0-9].*"//g |xargs qcheck

вместо qcheck можно equery check (app-portage/portage-utils и app-portage/gentoolkit соответственно)

[ArtSh]

Выясняется, что gcc-config его сделал.

Это только предположение, и кроме того это исполняемый файл а не ссылка. Судя по времени, он был сделан за 4 секунды до внесения записи в emerge.log об установке gcc-config и на секунду позже создания /usr/bin/gcc-config, судя по всему в pkg_postinst ...

[serzh-z]

Это только предположение, и кроме того это исполняемый файл а не ссылка.

↑

Поиск в сети, ваше предположение и, в конце концов, анализ кода /usr/bin/gcc-config убедили, что gcc32 - является продуктом gcc-config. Теперь я могу это утвержать.