Актуальность флагов пакетов
globus 6 февраля, 2016 - 16:01
Здравия!
Стал замечать, что существует несоответствие между флагами пакета, выводимыми по eix package, и в grep flag|pkg /usr/portage/profiles/use[.local].desc. Надо полагать, что по eix актуальность выше, так? use[.local].desc не спешать актуализировать. Так вот, в свете этого, где можно посмотреть актуальные описания флагов? Пытался в .ebuild-ах, ничего не нашёл.
»
- Для комментирования войдите или зарегистрируйтесь
Флаги USE вешь несколько
Флаги USE вешь несколько искусственная, поскольку большинство разработчиков о них не подозревает. При сборке пакета юс изменяет его конфигурацию, добавляя некоторые свойства и (возможно) добавляя некоторые зависимости. Соответственно если вам хочется узнать что именно делает флаг в пакете нужно посмотреть его ебилд, откуда (как правило) извлекается опция запуска скрипта configure в исходниках пакета. Данный скрипт, как правило, самодокументирован (configure --help), кое какую инфу можно выудить через него. Более полная информация может быть расположена в сурсах в разделе документации по сборке пакета или на его официальном сайте, понятно что наличие подобной документации есть исключительная заслуга разработчика. Стоит заметить что подобная информация в подавляющих случаях не нужна.
.
Не «искусственная», а «естественная» и объективная.
Просто нужно помнить, что помимо собственно разработки приложения есть отдельная задача его интеграции в некоторый дистрибутив.
А USE-флаги предоставляют «пользователю» доступ к некоторым из параметров конфигурации пакета.
Или устанавливает дополнительные файлы в качестве runtime dependencies.
Динозавр!
Автотулзы используются далеко не везде.
А с учётом общих тенденций к упадку культуры в реалиях голоцена редкостью стала простая корректность системы сборки, не говоря о документации.
При наличии правильных и достаточно полных скриптов сборки оно действительно избыточно.
Только это требование уже давно превратилось в приятное исключение.
:wq
--
Live free or die
Топикстартер попросил помощь.
Топикстартер попросил помощь. Я указал дорогу коей пользовался сам. Умный поймет, а дураку оно и не надо.
Ну а теперь окажем помощь вам, по пунктам :
1) Юс искусственная вещь, прослойка между юзером и системой сборки. О чем и было сказано.
2) runtime dependencies переводится как зависимости времени исполнения, и полагаю что в контексте вопроса это не сильно отличается от словосочетания "некоторые зависимости"
3) Наклеивать яркие ярлычки, я полагаю, значительно легче чем расписать способ добывания информации из (к примеру) cmake
4) Не знаю чем вы пользуетесь. В том дистрибутиве, который использую я мне приходилось разбирать ебилд самбы, скрипты конфигурации приснопамятных автотузл и писать багрепорт на некорректный ебилд. Но это было года два назад, и всего лишь с одним пакетом, и исключительно при сборке его в кластерном исполнении. Я не считал количество пакетов в своей системе но полагаю даже соотношение 1 к 10 в этом случае можно назвать продавляющим.
PS
Форум, я полагаю, создан ради помощи страждущему. Не можешь помочь - молчи.
.
Дело в том, что, как показывает дальнейшее обсуждение, «дорога коей пользовался сам» не вполне соответствует вопросу ТС.
Попытка же помочь мне в лучшем случае показывает непонимание диалектики бытия СПО.
Где, например, с точки зрения разработчика как правило практикуется встраивание дерева исходников зависимостей.
При том, что с точки зрения компоновки дистрибутива правильным, хотя и не всегда возможным, является использование разделяемых библиотек, устанавливаемых отдельным пакетом.
Что явным образом отображается и в используемой системе сборки (в начальном приближении опции для использования системных зависимостей достаточно часто отсутствуют).
Из примеров, которые знаю навскидку и которые в дереве — смотрите например на bgo историю зависимостей и патча (к системе сборки)
dev-db/tora. На примере зависимости от библиотекиdev-libs/ferrisloki.Ещё там же (в системе сборки) для альфы 3.0.0 можно поискать фиксацию текущего статуса структуры зависимостей (без поддержки Oracle
3.0.0_pre20140929-r1не собирается, этот факт отражён в зависимостях ебилда (сущность столь же «искусственная», сколь и USE-флаги, но не в системе сборки).:wq
--
Live free or die
.
Несоответствие в смысле списка флагов?
eixпишет туда сумму флагов ебилда и/etc/portage/package.use.Соответственно, если из ебилда флаг убрали, но ты не обновил список, в выводе eix у тебя он так и будет висеть.
А с учётом того, что флаги могут появляться в рамках пакета (и даже слота, с различием только по версиям)… просто стоит подумать и согласиться с констатацией рудиментарного характера поддержки USE-флагов в
eix.И, если тебя интересуют именно флаги, то использовать более подходящую утилиту.
equery u ATOMв помощь.В профиле же у тебя первичная база флагов. Что, впрочем, не гарантирует отсутствия ошибок.
:wq
--
Live free or die
Да, несоответствие. По eix
Да, несоответствие. По eix флаг есть, а в /usr/portage/profiles/use[.local].desc нет. Или наоборот. Интересует, естественно, описание флагов. Спасибо, попробую equery u ATOM.
/
profiles/use.local.desc— локальные флаги (флаги конкретных пакетов), «лишних» относительно выводаeixфлагов показывать не должен.profiles/use.desc— глобальные флаги. Очевидно, что в рамках конкретного пакета определено лишь подмножество списка.ЗЫ: Ещё, если смотреть не от пакета, а от флага, можно рекомендовать утилиту
euse.:wq
--
Live free or die
.
В частном конкретном ебилде используются не все глобальные USE-флаги.
+ cледствие прописывания в
package.useне необходимого минимума (флагов, которые ты хочешь включить или выключить или зафиксировать), но всех флагов, присутствующих на момент внесения вpackage.use.Не побоюсь изречь банальное: принцип тот же, что и с конфигурационными файлами: знаешь что тебе нужно — то и прописываешь, не знаешь — ничего не делаешь (соглашаешься с умолчаниями).
:wq
--
Live free or die