пятница, 19 октября 2012 г.

Portage: хочется странного

Как выяснилось, многие, даже довольно опытные, пользователи генты почему-то не читают доки.
Это порождает порой довольно глупые мифы.
Например о муках изменения и поддержания ебилдов, в которые запиливаются свои патчи и/или изменяются переменные и функции.
Вот для таких лентяев и решил на простом языке написать - как изменить ебилд, не изменяя ебилд :3.
Ну и по мелочи - о не очень распространённых возможностях портажа среди используемых.

make.conf
Все знают про этот файл и его содержимое.
Но не все знают, что у каждого пакета может быть свой такой "make.conf".
В /etc/portage/env/ создаём файл, например, ololo.conf.
Он должен иметь такой же формат как и make.conf.
Так же как и make.conf он может задавать такие вещи как FEATURES, в отличии от индивидуального bashrc пакета.(об этом ниже)
Для того чтобы портаж стал использовать наш ololo.conf для нужного нам пакета в /etc/portage/package.env необходимо указать для какого пакета использовать его.
Формат - "пакет конфиг", например:
lol-apps/trololo ololo.conf
кол-во конфигов не ограничено одним.
Этот приём используется, например, в crossdev.
Стоит учитывать, что этот "персональный make.conf" подчиняется всем правилам make.conf, в том числе параметры, заданные в нём, имеют более низкий приоритет, чем таковые в, пусть, package.use.
Т.е. если в этом конфиге задать юз "-use", а в package.use "use", то использоваться будет последний.
bashrc
Про этот файл и его возможности знают многие, но как оказалось, не все.
Коротко - в этот файл можно запилить "странные" вещи.
Но ещё меньше людей знают, что такой файл может быть у каждого пакета свой.
Такие файлы живут в /etc/portage/env/ и могут иметь следующее расположение и имена:
/etc/portage/env/${CATEGORY}/${PN}
/etc/portage/env/${CATEGORY}/${PN}:${SLOT}
/etc/portage/env/${CATEGORY}/${P}
/etc/portage/env/${CATEGORY}/${PF}
Они подчиняются тем же правилам, что и "общий" bashrc.
В них мы можем изменять/убирать/добавлять переменные и функции из ебилдов.
Например я не люблю косые табы chromium-а, для того чтобы исправить это недоразумение, мне надо использовать 1 патч(об этом ниже) и заменить несколько десятков png-шек перед сборкой.
Для замены оных в /etc/portage/env/www-client/chromium написал следующее
pre_src_compile () 
{ 
    cp -R /home/megabaks/some_trash/chromium/* .
}
Теперь при сборке любой версии chromium мои изменённые файлы будут раскладываться по местам автоматически.
Так же можно изменять функции ебилда на своё усмотрение и получать...изменённый ебилд, который не изменяли :3.
Не надо при каждом обновлении править ебилд, прогонять manifest/digest и выполнять прочие ненужные манипуляции.
Чуть более подробно.
patches
Довольно часто возникает необходимость наложить патч на пакет, особенно когда "хочется странного".
Править ебилд не нужно, это мы уже выяснили, можно просто перепилить/добавить функцию, но можно и проще.
Есть такая функция в eutils.eclass как epatch_user.
Она позволяет накладывать патчи без правки ебилдов.
Патчи должны лежать в одной из директории
/etc/portage/patches/${CATEGORY}/${PN}
/etc/portage/patches/${CATEGORY}/${P}
/etc/portage/patches/${CATEGORY}/${PF}
если не получается так (пока такое может быть), то можно воспользоваться авто_патчером.
Это тоже избавляет от необходимости правки ебилда как такового.
Пока вроде всё, что вспомнилось...
Да, не пытайтесь изменить RO переменные :)
A
CATEGORY
D
DEFINED_PHASES
DEPEND
DESCRIPTION
EAPI
EBUILD
EBUILD_PHASE
EBUILD_PHASE_FUNC
EBUILD_SH_ARGS
ECLASSDIR
EMERGE_FROM
FILESDIR
HDEPEND
HOMEPAGE
INHERITED
IUSE
KEYWORDS
LICENSE
MERGE_TYPE
P
PDEPEND
PF
PM_EBUILD_HOOK_DIR
PN
PORTAGE_ACTUAL_DISTDIR
PORTAGE_ARCHLIST
PORTAGE_BASHRC
PORTAGE_BIN_PATH
PORTAGE_BINPKG_FILE
PORTAGE_BINPKG_TAR_OPTS
PORTAGE_BINPKG_TMPFILE
PORTAGE_BUILDDIR
PORTAGE_BUNZIP2_COMMAND
PORTAGE_BZIP2_COMMAND
PORTAGE_COLORMAP
PORTAGE_CONFIGROOT
PORTAGE_DEBUG
PORTAGE_DEPCACHEDIR
PORTAGE_EBUILD_EXIT_FILE
PORTAGE_GID
PORTAGE_GRPNAME
__PORTAGE_HELPER
PORTAGE_INST_GID
PORTAGE_INST_UID
PORTAGE_IPC_DAEMON
PORTAGE_IUSE
PORTAGE_LOG_FILE
PORTAGE_MUTABLE_FILTERED_VARS
PORTAGE_OVERRIDE_EPREFIX
PORTAGE_PYM_PATH
PORTAGE_PYTHON
PORTAGE_READONLY_METADATA
PORTAGE_READONLY_VARS
PORTAGE_REPO_NAME
PORTAGE_RESTRICT
PORTAGE_SAVED_READONLY_VARS
PORTAGE_SIGPIPE_STATUS
__PORTAGE_TEST_HARDLINK_LOCKS
PORTAGE_TMPDIR
PORTAGE_UPDATE_ENV
PORTAGE_USERNAME
PORTAGE_VERBOSE
PORTAGE_WORKDIR_MODE
PORTDIR
PORTDIR_OVERLAY
PR
PROFILE_PATHS
PROVIDE
PV
PVR
RDEPEND
REPLACED_BY_VERSION
REPLACING_VERSIONS
REPOSITORY
REQUIRED_USE
RESTRICT
SLOT
SRC_URI
T
WORKDIR
всё равно не получится...

4 комментария :

  1. Этот комментарий был удален автором.

    ОтветитьУдалить
  2. Отлично.. для отдельных пакетов это уже юзается мной давно.
    А вот что ты посоветуешь для оверрайда CFLAGS сразу группы приложений.. например - собрать тотже leechcraft из гита под определенные флаги?
    Создавать кадждому ${CATEGORY} и ${PN} руками - гемор, при том, что и категория и пакнэйм у них разный.
    Прошу понять правильно - не хочется скрипта, прописывающего все нужное для каждого пакета. Хочется универсального решения а-ля echo "ФЛАГИ" >> /portage/env/leechcraft/make.conf
    ну и чтобы оверрайдились только прописанные там опции.
    Есть конечно сеты.. можно бы сделать @leechcraft и туда включить все заведомо (не)нужное... Но не работает оно почему-то.

    ОтветитьУдалить
    Ответы
    1. а если использовать так называемые wildcard-ы?
      типа
      */leechcraft*
      или вообще никаких общих шаблонов не придумать?

      Удалить
  3. хм.. это первое, что приходит на ум.. Но, согласись, это кустарщина. И она даже чем-то порочит ту систему, о которой ты говоришь.
    Ибо то, что предлагаешь ты в виде /etc/portage/bashrc вполне приемлемо. Но если каждый начнет ТУДА чего-то писать свое, да еще и с wildcards - мы ж погибнем как класс..
    Посему систему отфильтровки пакетов имхо нужно учесть в самом bashrc. Как это предлагается для пакетов под icc например. И как это работает в портаже под сеты.
    А сами пакеты подпадающие под некоторое правило (с вайлдкардами даже) - кидать в отдельный файл (вот тут юзер нехай сам мыслит).
    Т.е. мы фактически дадим систему, под которую будет работать ВСЕ, и вины разраба за то, что юзер внес в свой need_other_CFLAGS.conf_или_что ему_там_захочется некие пакеты останется целиком на юзере.
    PS. Я немного не в курсе насколько ты к мейнстриму gentoo относишься, но имхо вот это решение (bashrc) нужно проталкивать всемерно. Ибо лично я узнал о таком только от тебя. А если нормально развернуть - это всем понравится.

    ОтветитьУдалить