Gentoo Linux выпускает 20140826 LiveDVD - Iron Penguin Edition

кучу функций без аргументов которые работают с волшебными константами A, S, P, D и прочими. Это печально, ИМХО.

Да вы, батенька, не понимаете основ. Идея в том, что задаешь в ебилде переменные и все работает. Ебилд по возможности декларативен. Если приходится писать код, то что-то немного не так с пакетом.

Для них мейнтейнинг это просто копирование файлика.

Перед этим там надо разгребсти завалы костылей. Вот я когда на этот ебилд смотрю, мне становится грустнооооо.

Просто каждый делает что хочет лично он, а не что «нужно».

нужно кому?

Вот у меня все работает. А что не работает, то я майнтэйню и начинает работать. Почему меня должно заботить, что нужно vurdalak, он мне деньги платит?

Они же уже мейнтейнеры.

Вот они и майнтэйнят что считают нужным.

Да вы, батенька, не понимаете основ. Идея в том, что задаешь в ебилде переменные и все работает. Ебилд по возможности декларативен. Если приходится писать код, то что-то немного не так с пакетом.

Ну как бы сборка подразумевает написание кода. Поэтому и получаются костыли от попытки впихнуть невпихуемое в декларативную модель.

нужно кому?

Проекту. Нужность должен решать менеджер ветки (хз как это называется, «кеды», «питон» и так далее) и менеджер проекта.

Почему меня должно заботить, что нужно vurdalak, он мне деньги платит?

Ну вот и я о том же. Каждый делает то что лично его заботит.

Ну вот я озвучил проблему. Можешь ткнуть в решение?

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

Ну как бы сборка подразумевает написание кода.

Ой. Сборка подразумевает вызвать стандартные средства конфигурации/сборки с параметрами. А если это не так, то ракет крив.

Поэтому и получаются костыли от попытки впихнуть невпихуемое в декларативную модель.

УМВР, ЧЯДНТ?

Полное описание такое. Там для сборки нужно чтобы сборка запускалась из каталога, внутри которого лежит: github.com/syncthing/${PN}, а в нём сорцы. По умолчанию портеж их распаковывает в текущий каталог, а мне нужно чтобы они сложились в вышеуказанный путь внутри него.

Сборка подразумевает вызвать стандартные средства конфигурации/сборки с параметрами.

Это у идеального проекта в вакууме, т.е. частный случай сборки, когда набор команд состоит из одной — запустить какой-то инструмент с build-файлом в качестве параметра. У реальных же проектов количество команд растёт пропорционально проекту.

Проекту. Нужность должен решать менеджер ветки (хз как это называется, «кеды», «питон» и так далее) и менеджер проекта.

)) И к какому относится i2p?

Ну вот и я о том же. Каждый делает то что лично его заботит.

Just for fun and just for lulz основополагающие принципы. На них Гента и стоит. Кому не нравится, заплатите красношапке за впиливание нужных фич и пользуйтесь тем, что они напилят. Или эпплу. Или можно заплатить генту фундэйшн или лично майнтэйнеру. Вот я за 3000 злотых готов запилить i2p и связанные ебилды (со своих беру дешево).

mv в src_prepare кто-то запрещает?

Я сейчас так и делаю (только mv в unpack, а не prepare). Но это выглядит как костыль, потому что вместо распаковки сразу в нужное место мы сначала распаковуем в ненуженое, а потом двигаем.

Потому что кривой пакет, надо им заслать патч. А у пана перфекционизьма.

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

Могу посоветовать спросить в gentoo-dev и предложить изменения в EAPI 6. Как раз его готовят.

gentoo-dev@lists.gentoo.org

возможности участвовать в принятии кардинальных решений.

Крупные проекты проводят регулярные собрания, на которых обсуждаются ключевые решения, как правило - голосованием. Так делают как минимум в Gentoo Qt, Gentoo KDE, ну и Gentoo Council конечно же.

В мелких проектах как правило все ебилды одной группы(herd) обслуживаются сообща, если нет выделенного(dedicated) мэйнтэйнера. Это легко проверить по метадате - если там есть только тег <herd> без тега <maintainer> - этот ебилд мэйнтэйнят всем скопом.

выделение виртуалки с гентой под личное пользование

Такое практикуется только для arch testing на экзотических архитектурах. Например, я уже упоминал в каком-то другом треде, что я имею доступ к паре виртуалок с архитектурой s390.

Официальные доки разбросаны по разным местам и не очень полные

Что конкретно не ясно по написанию именно ебилдов?

Если ты прочёл:

1) devmanual;
2) Gentoo developer handbook;
3) PMS; 4) код екласса под ту билдсистему/язык, на котором написан пакет, на который ты хочешь запилить ебилд.

Если после этого у тебя остались вопросы, то это либо что-то очень специфическое по работе самого portage(тебе ответят на #gentoo-portage), либо ты что-то недопонял и лучше уточнить у живого человека(тебе прямой путь на #gentoo-dev-help)

это не поддерживается, лол, это у вас проект кривой и гента такое не соберёт

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

Помню, как приходилось бампать новые версии методом детальной вычитки КАЖДОГО коммита. Потому что по-другому понять, что там накручено не представлялось возможным...

кучу функций без аргументов которые работают с волшебными константами A, S, P, D

Что такое P, PV, PN, PF и PR - описано в devmanual

Что такое P, PV, PN, PF и PR - описано в devmanual

Я знаю. Я к тому, что функции без аргументов, которые используют вместо них глобальные переменные, это зло. Но это моё ИМХО.

Особенность ебилдов в том, что эти глобальные переменные остаются одними и теми на протяжении всего времени сборки по определению. Это константы (имя пакета, версия, коммит в гите и так далее) и делать их аргументами функций — глупо и прямой путь к ошибкам.

WORKDIR и S не такие уж и константы.

Устанавливаются один раз. Просто + к этому имеют дефолтное значение.

Передавать их аргументом не имеет смысла, ибо если человек изменяет их от функции к функции — он где-то что-то делает не так.

А вообще, если что-то кажется кривым и есть аргументы, велкам ту мэйл-лист с предложениями для EAPI 6.

У нас нет Линуса, поэтому даже не скажут, что ю ар э моррон.

У нас нет Линуса, поэтому даже не скажут, что ю ар э моррон.

А как же этот, который блочит ебилды? Поляк какой-то :)

Попроше пана, кто кого когда заблочил?

Часто вижу сообщения от портежа, что такой-то ебилд будет заблокирован такого-то числа by этот поляк. Имя его не введу, так как у меня нет таких символов на клавиатуре, но оно означает Михаил Горный.

А, пан маскирование блоком называть изволит. )

Пан Михал наводит порядок. И все правильно делает. Там обычно написано, почему тот или иной ебилд был замаскирован.

(Для справки: правильно Михал Гурны).

Пан Михал наводит порядок. И все правильно делает.

Так я и не спорю. Я просто думал, что раз он столько маскирует, значит он что-то вроде Линуса, уничтожающего «плохие» ебилды :)

А есть какой-то простой способ посмотреть список пакетов без мейнтейнера по категории? Чтобы можно было подобрать что-то такое и понять, могу ли я чем-то помочь.

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

А есть какой-то простой способ посмотреть список пакетов без мейнтейнера по категории?

jauhien@zcj sci % grep -r maintainer-needed /usr/portage/dev-python | grep metadata.xml
/usr/portage/dev-python/pylast/metadata.xml:		<email>maintainer-needed@gentoo.org</email>
/usr/portage/dev-python/xmpppy/metadata.xml:		<email>maintainer-needed@gentoo.org</email>
/usr/portage/dev-python/pysyck/metadata.xml:		<email>maintainer-needed@gentoo.org</email>
/usr/portage/dev-python/colubrid/metadata.xml:  <email>maintainer-needed@gentoo.org</email>
/usr/portage/dev-python/audioread/metadata.xml:		<email>maintainer-needed@gentoo.org</email>
/usr/portage/dev-python/pyechonest/metadata.xml:		<email>maintainer-needed@gentoo.org</email>
/usr/portage/dev-python/python-dsv/metadata.xml:  <maintainer><email>maintainer-needed@gentoo.org</email></maintainer>
/usr/portage/dev-python/pyacoustid/metadata.xml:		<email>maintainer-needed@gentoo.org</email>
/usr/portage/dev-python/python-musicbrainz-ngs/metadata.xml:		<email>maintainer-needed@gentoo.org</email>
/usr/portage/dev-python/remoteobjects/metadata.xml:  <email>maintainer-needed@gentoo.org</email>
/usr/portage/dev-python/rtf2xml/metadata.xml:  <email>maintainer-needed@gentoo.org</email>
/usr/portage/dev-python/bluelet/metadata.xml:		<email>maintainer-needed@gentoo.org</email>

Ладно, буду тренироваться на yacy. Постараюсь сделать так, чтобы он собирался из сорцов и без jar'ок внутри тарболла.

Потому что с тем же i2p от меня профита никакого нет, там слишком сложный проект.

Час тому был же простой проект, что там майнтэйнить? Только ебилд копировать. ;-)

Для мейнтейна он простой. Сложный для написания первый раз. Я просто не такой специалист в ебилдах, чтобы знать, как там положено перепатчивать библиотеки и всё такое прочее.

Что за yacy? Когда надо будет закоммитить что-нибудь в дерево, можно просто скастовать меня. )

Это p2p поисковик. Я когда-то давно положил его ебилд к себе в оверлей, но потом забил. Сейчас есть повод обновить. Пока там просто распаковывается тарболл, но можно например заменить тамошние библиотеки на system-wide варианты.

Когда надо будет закоммитить что-нибудь в дерево, можно просто скастовать меня. )

Напиши в жабир, на лоре неудобно это обсуждать.

Вот я за 3000 злотых готов запилить i2p и связанные ебилды (со своих беру дешево).

Запилить или просто написать? Ничего сложного для меня в написании ебилда нет, просто надо девмануал читать (ссылки приводились вами же), но 3к как-то дороговато для простого сборочного файлика по сути.

Запилить или просто написать?

Просто не получится. )

3к как-то дороговато для простого сборочного файлика по сути.

По-моему само то.

все такие типо гентушники, а сами бубунту по инструкциям юзают)

Дистр хорош! Вот буду собирать новую машинку и его обязательно там заведу

Обрати внимание на мой срачь с разработчиками...

Ну и как вам результат?