Исходное сообщение
"Летнее обновление ALT p9 starterkits " Отправлено Michael Shigorin, 15-Июн-20 17:50
> сейчас лучше опакечивать бошьшинство софта со своими библами Это не "лучше" или "хуже", это по сути выбор вида статика/динамика (в чём-то аналогичный выбору "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

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> сейчас лучше опакечивать бошьшинство софта со своими библами > Это не "лучше" или "хуже", это по сути выбор вида статика/динамика (в > чём-то аналогичный выбору "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
	Введите код, изображенный на картинке: