> сейчас лучше опакечивать бошьшинство софта со своими библамиЭто не "лучше" или "хуже", это по сути выбор вида статика/динамика (в чём-то аналогичный выбору "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