> сейчас лучше опакечивать бошьшинство софта со своими библами

Это не "лучше" или "хуже", это по сути выбор вида статика/динамика (в чём-то аналогичный выбору "hosts или DNS").  Если опакечивать без понимания такой сути -- будет точно хуже; например, из-за статической линковки или "статической" упаковки дырявых/глючных версий библиотек.

Одни детишки (забыл уже имя того проекта, хотя наверняка можно в архиве найти при надобности) лет пятнадцать-двадцать назад затеяли статически собранный дистрибутив, потому что их как слакваристов то ли оскорбляли, то ли унижали зависимости.  Запоролись уже технически они где-то в районе OOo, но вопросы по существу возникали ещё в районе pam, помнится (хотя не помню, был ли pam в тогдашней слаквари -- он ведь изоморфную проблему решает).

> Поставил я какой-то софт скажем, может даже временно, а он 100
> пакетов зависимостей тянет, в каждом по миллиону файлов.

Для таких случаев и есть aptitude (с не сильно давних пор и собственно apt в debian и производных научился писать метаданные о происхождении запроса на каждый конкретный пакет -- явно велено али по зависимостям потянулся); при этом в общем и в целом aptitude install softina; aptitude remove softina должно привести примерно к тому же виду системы, что и был.

Если что-то шибко развесистое или "временно" подразумевает достаточно длительный период, за который поставленные "паровозиком" пакеты могут понадобиться другим пакетам (либо обновляться?) -- картина может быть другая.  Но тогда и стенды/виртуалки/контейнеры/чруты бывают.

> Конечному пользователю (мне) всё это не надо и только мешается.

Вам оно мешается в плане обозримости списка установленных пакетов, так понимаю?  Просто если для работы softina эти стомильёнов файлов действительно нужны -- тут вариантов не особо-то и много.

> Или другой пример - 2 софта требуют перл. и само собой хороший тон
> в Линуксах чтобы они юзали системный перл. Хотя смысла в этом
> немного. Лучше каждому пакету дать его минимальный и чтобы в PATH
> и PERLLIB их конечно не было.

А чем лучше?  Необходимостью потом эти перлы в случаях необходимости (что даже и с perl5 бывает) поддерживать в N-кратном объёме?

> Тогда не надо заботиться что обнова "общего" Перла что-то сломает.
> Подобная философия кстати лучше сочетается с ахривами типа CPAN и
> говноскрипта и вообще всего.

За CPAN не скажу, про "вообще всего" это Вы зря, ну а остальное сразу бы и сказали.

> С минусами такого подхода можно разобраться.

Вот сперва разберитесь, а потом уже отбивайтесь от благодарного человечества, рвущегося закидать Вас амброзиями...

PS: мой старый приятель давным-давно написал такую вот статью: http://www.linuxlib.ru/Linux/idealsa.htm