USE-флагами удобнее пользоваться, или что?

Да.

USE флаги могут притягивать зависимости. Хочешь поддержку ogg где-то там, указал USE флаг, оно мало того, что опцию в ./configure передало, так еще и соотв. либу доустановило, если ее еще нет. Если просто опцией компиляции, то компиляция просто оборвется где-то посредине, и ты будешь вчитываться в сообщение об ошибке и пытаться понять, какой же либы не хватает.

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

Иногда опции компиляции могут противоречить друг другу. Например, есть софт, который можно установить только с поддержкой qt4 или qt5 (но не вместе). С опциями компиляции ты об этом узнаешь только когда ./configure упадет. А так это разруливается еще при парсинге USE флагов. Или наоборот: один USE флаг требует другого. Или какой-то USE флаг требует зависимость с определенным (другим) USE флагом. Много чего.

Потом - опции компиляции могут называться по-разному в разном софте. А глобальные USE флаги обеспечивают одинаковое название для всех программ, для которых они есть. И ты можешь задать глобальный USE флаг в make.conf и быть уверенным, что вся система, т. е. все релевантные программы будут собраны с нужной тебе функциональностью.

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

То есть в некоторых случаях USE-флагов может быть больше, чем опций сборки? Интересно.

А вообще, спасибо большое за разъяснение, именно такой ответ я и хотел получить. Теперь думаю, может установить Gentoo :)

Почему гентушники хвастаются USE-флагами, когда у всех дистрибутивов есть возможно делать то же самое, используя опции сборки?

USE флаги сами по себе ничто кроме того что они высокоуровневые «выключатели»… слой абстракции над теми самыми опциями сборки.

Вот только ты забываешь во первых о том, что существует немеренное количество самых разных систем сборки. И одно и то-же по смыслу в них может обозначатся совершенно разными опциями сборки.

Во вторых иногда сама по себе опция сборки без некой зависимости делает ровно ничего. Если некоему софту нужен qt5 а его у тебя нет но ты упорно пишешь "--enable-qt4" этим самым ты не добьешься ровно ничего до тех пор пока не соберешь qt5.

Вот тут мы приходим к мысли о том, что этими самыми опциями нечто должно заведовать.

А вообще немедленно поднял свою жопку пошел отсюда вон и до завтрашнего утра собрал мне 32х битный LFS с 64х битным ядром без gtk но с qt в каждом четном собираемом пакете и наоборот в нечетном! И вот тогда мы поговорим с тобой об USE флагах и их удобстве.

И вот тогда мы поговорим с тобой об USE флагах и их удобстве.

Да я уже прикинул. В source-based дистрах без use-флагов(или аналогов) будет действительно тяжко.

Другое дело, что если ты используешь бинарный дистр и лишь в редком случае компилируешь что-то критичное, тогда в use-флагах большого смысла нет.

Что такое «опции сборки»? Если ты имеешь в виду параметры ./configure или cmake и т.д., то USE-флаги лучше тем, что они находятся на уровне менеджера пакетов. Устанавливать софт из сорцов со своими опциями сборки, конечно, в любом дистрибутиве можно, но менеджеры пакетов на что?

В итоге вопрос «удобнее USE-флагами пользоваться что-ли, чем опциями сборки?» сводится к «удобнее ставить софт менеджерами пакетов что-ли, чем из сорцов?», на что ответ очевиден.

В source-based дистрах без use-флагов(или аналогов) будет действительно тяжко.

Если ты под «действительно тяжко» имел в виду сраный адовый ад то да.

Другое дело, что если ты используешь бинарный дистр и лишь в редком случае компилируешь что-то критичное, тогда в use-флагах большого смысла нет.

Сходи разберись в вопросе. Portage метапакетный манагер с кучей таких фич о которых ты и понятия не имел. А gentoo легко и просто может быть и бинарным дистром в том числе.

Просто попробуй gentoo и LFS.

Другое дело, что если ты используешь бинарный дистр и лишь в редком случае компилируешь что-то критичное, тогда в use-флагах большого смысла нет.

Ага, поэтому в Gentoo vim и gvim лежат в трёх пакетах: vim-core, vim и gvim, а, например, в Debian: vim, vim-tiny, vim-common, vim-runtime, vim-doc, vim-gnome, vim-gtk, vim-nox, если ничего не забыл.

А gentoo легко и просто может быть и бинарным дистром в том числе.

Не совсем просто. subslot hell остается в силе, например.

Не совсем просто. subslot hell остается в силе, например.

По крайней мере генте это сделать гораздо проще нежели чем капетным манагерам из бинарных дистров стать ещё и сырцовым.

Такой задачи перед ними не ставилось, так что логично.

А где бинарники для генту брать? У Calculate воровать?

А где бинарники для генту брать? У Calculate воровать?

Ты не поверишь но они есть и без calculat-ов.

А где они есть?

В source-based дистрах без use-флагов(или аналогов) будет действительно тяжко

Эти б слова да разработчикам source-based дистрибутивов в уши.

я бы даже сказал, что них из бинарников у них только то, что идёт в комплекте на диске, не считая бинарников, что есть в гентушных репах

Бинарные репы самой генты или не слышал?

Ну да, я не думал, что у неё есть бинарные репы. Логика вроде «зачем source-based дистрибутиву бинарные репы».

Не слышал. Можно ссылку?

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

так точно то же самое ведь можно сделать на любом дистрибутиве, используя опции сборки

ну если ты совсем мазохист то то собирай каждый пакет с опциями в ./configure

На http://bfy.tw/C2CQ мне не жалко

Есть фатальный недостаток — навязывание маразма майнтейнеров под видом прозрачности. Щитаю нужно определится, трусы или крестик; использую бинарный дистрибутив с частью собранных «by LFS way» пакетов.

Я же тебе писал, что в других дистрибах у тебя нет возможности влиять на опции сборки. Пакеты в собранном виде. Генту же позволяет удобно и централизовано гибко управлять сборкой пакетов прямо на месте. Вдупли уже разницу между бинарными пакетами и сборкой из исходников, чтоб не задавать тупых вопросов.

Предложение погуглить подано оригинально, но вот название «Tinderbox» слышу впервые, как я мог найти тогда его?

За информацию спасибо.

Предложение погуглить подано оригинально, но вот название «Tinderbox» слышу впервые, как я мог найти тогда его?

Наверное надо быть более пытливым. Иначе как я узнал и нашел? И да «зачем source-based дистрибутиву бинарные репы» чтоб ускорять развертывание типовых систем или не? И потом ежедневные снапшоты портежей и stage разве не наталкивают на мысль что если есть собранная iso-шка то неужели непонятно что и бинарные пакеты где-то да будут. Вот я правда удивляюсь толи гентушник не тот пошел…

Я не считаю это ответом на свой вопрос. Не нужно ничего выяснять, просто мы слишком разные с тобой, чтобы найти общий язык.

Уууу... как все плохо!

Просто ты понял мой вопрос не так, как я это предполагал. Поэтому и твой ответ не соответствует тому, что я спрашивал.

Просто либо ты тупой и задаешь тупые вопросы и не понимаешь ответы. Либо настолько жирный троль, что это все тупо и уныло.

покажы весь путь (список команд) от начала до конца — на примере какого-нибудь пакета (какого-нибудь дистрибутива)...

так точно то же самое ведь можно сделать на любом дистрибутиве, используя опции сборки

покажы весь путь (список команд) от начала до конца — на примере какого-нибудь пакета (какого-нибудь дистрибутива)...

...и да — под пакетом я подразумеваю именно *пакет* дистрибутива, а НЕ исходный код программы в том виде в котором она на сайте разработчика программы (то есть ./configure && make && make install ---- нам не интересно. редактируй именно *пакет*).

то есть — действия (по вставлению своих --enable-флагов в *пакет*) которые мы ожидаем от тебя — это должно быть что-то-такое что не внесёт смуту в существующую систему пакетов (пакетного манагера).

твоё внеднение --enable-флагов разумеется также не должно негативно влиять и на обновление программ (в том числе той куда ты внедрял эти enable) — так что не забудь показать нам ВСЁ (все-все-все команды) включая команды и для того как ты будешь вести отдельную git-ветку *пакета* в твоём git-репозитории..

ну всё! начинай демонстрировать! (пример).

затем сравним это с USE-флагами (включая поставленные условия по сохранению обновляемости и невнисения смуты в пакетную систему).

# P.S.: ну например возьми в качестве примера openssl — как раз очень показательно получится

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

Заметь почти все ответили тоже что и я, только другими словами и без наводки на то что тебе надо вдуплить сборку ПО чтоб тупых вопросов не задавать.

Я не особо понял, что ты тут написал. Думаю, это связанно с тем, что мы слишком разные люди с тобой. В реальной жизни я стараюсь избегать общения с «другими» людьми, во избежание непродуктивных диалогов и пустой траты времени.

Думаю, игнор-лист поможет реализовать мне это и в рамках данного сайта.

Просто хочу чтобы ты, и все остальные, кого я возможно добавлю в будущем в игнор-лист, знали: у меня нет каких-то обид на вас, просто мы слишком разные, чтобы найти общий язык; и нам обоим будет выгоднее, если мы перестанем тратить время на непродуктивное общение.

USE-флаги это также и абстракция над опциями сборки, для удобства.

хочу чтобы ты, и все остальные, кого я возможно добавлю в будущем в игнор-лист, знали: у меня нет каких-то обид на вас, просто мы слишком разные, чтобы найти общий язык

просто чтоб ты знал: мы приложим все возможные усилия чтобы ты извлёк нас из этих твоих игнор листов.. и будем стараться не оказаться там снова!

Зачем выдумывать то, чего не было? Будет на что ссылаться в будущем, а свой профиль не хочу этим засорять.

Хотя, знаешь, я даже загорелся идеей кидать всех «других» в игнор-лист. Надеюсь, в будущем мне будет с кем пообщаться, и это будут качественные люди. А если не выйдет, то начну с чистого листа ¯\_(ツ)_/¯. Хотя, с другой стороны, комментарий от любого человека может иметь вес, и я могу молча фильтровать «мусор». Но пусть это будет неким экспериментом по созданию своего мирка, мне интересно.

Просто чтоб ты знал: я тебя кинул в игнор-лист не за этот комментарий, но он был триггером на проверку твоего профиля.

P.S. Наверное мне надо будет реализовать время на игнор-лист для каждого человека, учитывая, что люди могут меняться.
_____
Чем-то напоминает концепцию тюрьмы, кек.