Может есть скрипт уже такой, может кто делал, чтобы прогнать ldd по /bin /sbin /usr/bin /usr/sbin /lib /usr/lib и получить список библиотек, которые есть в /lib /usr/lib, но нигде не присутствуют?
Этим ты не отследишь неиспользуемые библиотеки, записей о которых нет в базе пакетов. Так что revdep-rebuild обязателен, там он этот список в конце выкидывает.
lib.so и lib.so.6 это и есть дубликаты, то есть проверяй, ссылка это или нет, ссылки из списка удаляй. Битые ссылки, которые не указывают на файл библиотеки, совсем удаляй с диска.
> Битые ссылки я и так вижу красным в mc и могу прибить
Прошу прощения за маленький оффтоп. Для битых ссылок есть тулза:
emerge symlinks && man symlinks
symlinks -drv /
Одно "но" - работает в пределах одной файловой системы.
Тебе же не только битые ссылки нужны. > во втором списке - ссылка на lib.so.6, а в первом - файл lib.so.6.2.3, как отследить, что это один и тот же файл?
У них одно и то же название lib, сравнивай имена до первой точки.
Но зачем?
Кстати я не вполне всё-таки понимаю в чём проблема. Если у тебя что-то зависит от lib.so а что-то от lib.so.6.2.3, то и на диске тоже обязаны быть оба этих файла, поэтому задача сводится только к удалению файлов вида lib.so.6.2.3 и потом удалению битых ссылок.
Вопрос не в emerge --depclean :)
Вопрос в том, что можно умудриться получить библиотеку в системе, про которую менеджер знать ничего не будет, например ручной установкой.
В дженте такие библиотеки (если они ничем не используются) находятся с помощью revdep-rebuild, их список он вываливает в конце. У меня например он так ругается на пару самосборов в /usr/local/* для которых было лень писать ebuild :)
Не надо удалять ничего, ссылки вида lib.so, lib.so.6 -> lib.so.6.x.y.z мало того, должны быть, они ещё и опять создадутся командой ldconfig.
Поэтому, не майся ерундой.
Удаляешь неиспользуемые lib.so.6.x.y.z, вычищаешь битые ссылки на неё. Всё.