LINUX.ORG.RU

Параметры сборки пакета


0

1

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

Сложность в том, чтобы однозначно определить все параметры, с которыми был собран пакет, чтобы отделить разные сборки одного пакеты. Например, к нему добавляется файл с описанием пакета. Так вот, что в нем должно быть? Наверняка версия, архитектура, USE-флаги, с которыми он собран. Еще версия gcc и CFLAGS. Что еще нужно туда добавлять, чтобы это однозначно определяло нужный пакет?

И да, есть ли желающие это реализовывать? Я хочу, но я ленивый и кодер пока не очень хороший. Буду пытаться по мере сил.

★★★★★

Последнее исправление: vurdalak (всего исправлений: 1)

Просто ужас какой-то. Ты представляешь с каким количеством опций можно собрать ОДИН пакет? а тут их предлагается иметь много.

ZaeLam3l
()
Ответ на: комментарий от ZaeLam3l

ZaeLam3l> Ты представляешь с каким количеством опций можно собрать ОДИН пакет?

Онлайн-проверка списка опций часто быстрее компиляции.

vurdalak ★★★★★
() автор топика

Вероятность совпадения версий, USE, {C,LD}FLAGS, и наличия широкого канала у раздащего крайне мала. К.О.

anon_666
()
Ответ на: комментарий от anon_666

anon_666> Вероятность совпадения версий, USE, {C,LD}FLAGS, и наличия широкого канала у раздащего крайне мала. К.О.

По моим соображениям 95% гентушников используют генту с -march=native и последней для их ветки версии gcc. Различаются только архитектура, USE и версии библиотек, на которые завязано приложение.

vurdalak ★★★★★
() автор топика
Ответ на: комментарий от vurdalak

>95% гентушников используют генту с -march=native

Native разворачивается в разный набор флагов на каждом конкретном проце, не?

anon_666
()
Ответ на: комментарий от anon_666

anon_666> Native разворачивается в разный набор флагов на каждом конкретном проце, не?

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

vurdalak ★★★★★
() автор топика
Ответ на: комментарий от vurdalak

>Среди миллионов линуксоидов найдется хоть один с процом, подобным моему.

Cледуя опыту, у него либо канал 56k, либо его сбивает машина :3

anon_666
()
Ответ на: комментарий от anon_666

>>Среди миллионов линуксоидов найдется хоть один с процом, подобным моему.

Cледуя опыту, у него либо канал 56k, либо его сбивает машина :3


и у него *точно* другие юзфлаги :)

seed_stil ★★
()

Что-то я сомневаюсь, что гентушников миллионы

m0rph ★★★★★
()

Сложность в том, чтобы однозначно определить все параметры, с которыми был собран пакет, чтобы отделить разные сборки одного пакеты. Например, к нему добавляется файл с описанием пакета. Так вот, что в нем должно быть? Наверняка версия, архитектура, USE-флаги, с которыми он собран. Еще версия gcc и CFLAGS. Что еще нужно туда добавлять, чтобы это однозначно определяло нужный пакет?

на примере portage: в /var/lib/portage/.. есть IUSE флаги, с которыми собирался пакет. В общем случае, могут понадобиться переменные окружения, чуть ли не вообще все. Например, PATH показывает какая версия gcc собирала, CFLAGS/CXXFLAGS/LDFLAGS опции, make ... DESTDIR=... может использоваться установки в другое место, но это редко; CC=.../AS/LD указывает на компилятор/ассемблер/линкер. SYSROOT внутренняя переменная portage/emerge для кросскомпиляции и сборки в другое место и определения другого профиля. При кросскомпиляции может использоватья другой SYSROOT/CC/CFLAGS/PATH (например: CC=clang CC=i686-pc-mingw32-gcc, и т.п.)

IUSE= effective use флаги, из них есть как «нормальные», которые в ebuild транслируются напрямую через euse $(...) в опции (USE=foo в ./configure --enable-foo, USE=-foo в ./configure --disable-foo), так и специальные, вроде различных ABI (python2/python3, ruby18/ruby19, gtk/gtk3/introspection и т.п.) Эти специальные включаются другой формой euse c 3 параметрами, то есть в общем случае USE=foo может транслироваться в произвольный ./configure --enable-foobar или --with-feature=xyzzyasdf)

IUSE вычисляются каждый раз из /etc/make.conf USE=... + /etc/portage/package.use/cat-pkg/pkgname

строка в /etc/make.conf про архитектуру и оптимизации по умолчанию, архитектура

anonymous
()
Ответ на: комментарий от anonymous

но эта информация не полна. Например, я могу взять старый пакет под старый GTK2, который уже не собирается. Пособирать его по фазам: ebuild .../d4x-XXX.ebuild unpack configure; затем вручную похакать или запустить ./configure с нужными мне флагами, или добавить в conf.h.in GTK_DISABLE_DEPRECATED и переконфигурировать. Затем продолжаю сборку: ebuild .../d4x-XXX.ebuild compile install qmerge => ура, мы успешно собрали и установили несобирающийся из portage пакет.
Как сам понимаешь, в промежутке между фазами можно сделать всё что угодно. Поэтому не гарантируется, что пакет будет собран с теми USE флагами что в профиле portage, например.

anonymous
()
Ответ на: комментарий от anonymous

или взять 9999- ебилды, live scm сборки. Неизвестно насколько они актуальны, и старый устаревший может приводить к конфликтам, которые разрешатся, если обновить все 9999 на последнюю актуальную версию. Которая из них последняя (если у меня есть 2 оверлея с разными url, например) хз — определяется приоритетами оверлеев (а не актуальностью их обновлений, например).

anonymous
()

как с nix? Пробовал поставить? Какие впечатления, чего ему не хватает до генты?
С моей точки зрения:
1) USE-флагов;
2) /usr/portage/distfiles со стабильными именами foobar-1.2.tar.gz вместо /nix/store/{хеш}-foobar-1.2.tar.gz
3)атомарность изменений иногда играет против него

anonymous
()
Ответ на: комментарий от anonymous

3) в смысле, качали пакеты в /nix/store/..., потом они не смогли поставиться как в конфликте с bugpoint с llvm-2.7/clang-2.7 => атомарно обломалась операция, включая закачку. И пофиксив, надо закачивать заново.

Радует, что там всё на скриптах на перле написано, и можно их похакать до нужной функциональности.
Вообще, nix-env какой-то больно низкоуровневый, на уровне ebuild.sh,а не emerge.

anonymous
()
Ответ на: комментарий от ZaeLam3l

>Ты представляешь с каким количеством опций можно собрать ОДИН пакет? а тут их предлагается иметь много.

а представляешь, с каким количеством комбинаций опций можно собрать 2 пакета, тем более, если один понимает под USE=foo --enable-feature=asd, а другой пакет — USE=foo --enable-feature=qwerty ?

anonymous
()
Ответ на: комментарий от anonymous

ещё там должна быть или очень желательна информация о совместимости ABI.
например, libpng и фикс той ошибки. собрали его и поломали ABI. заново надо пересобирать, чтобы пофиксить.
плохо, что такой метаинформации толком и нет, trial&error. Что-то подобное пытаются эмулировать замаскированными USE-флагами, но полных гарантий нет, и инфа «замаскирован в апстриме» собирается постфактум.

anonymous
()
Ответ на: комментарий от anonymous

трабла «а у миня =dev-junk/foobar-1.2 нисобираиццо» => в модели Крипке проверка получила недостижимое состояние.
такого вообще не должно быть. То есть, функции перехода должны быть такие, чтобы всегда достижимо. А если внезапно при сборке облом, то несобираемое автоматически замаскируеццо с учётом имеющихся в остальном конфиге профиля опций и патчатся функции перехода с учётом замаскированного.

anonymous
()
Ответ на: комментарий от anonymous

то есть, хранится информация не та, когда конфликтов нет. А та, когда они потенциально возможны или как уже исторически протестировано случились. И чтобы фаза возможно=>протестировано сама вычислялась. (но это уже губозакаточную машинку надо), ну или хотя бы полуавтоматически.

anonymous
()
Ответ на: комментарий от anonymous

make.conf в данном случае вообще не нужен - он может быть не актуальным для отдельно взятого пакета
лучше bzgrep-ать по «„declare -x $TYPE=“ где TYPE это C/CXX/LD/*/FLAGS или что-либо ещё

megabaks ★★★★
()
Ответ на: комментарий от megabaks

например

[ megabaks@desktop ] ~ $ bzgrep "declare -x USE=" /var/db/pkg/app-admin/conky-1.8.1/environment.bz2 
declare -x USE="X curl elibc_glibc hddtemp imlib iostats kernel_linux ncurses nvidia portmon rss truetype userland_GNU x86"
[ megabaks@desktop ] ~ $ 

megabaks ★★★★
()
Ответ на: комментарий от anonymous

как с nix? Пробовал поставить? Какие впечатления, чего ему не хватает до генты?

Поставил, потыкал. Собирать не пробовал, только устанавливал бинарники. Долго разбирался с настройкой, которая реализована для всего в одном файле (с одной стороны удобно, с другой непривычно).

vurdalak ★★★★★
() автор топика
Ответ на: комментарий от mky

mky> А безопасность? Кто эти пакет подписывать будет?

Допустим подпись будет добавлять emerge, собирая эти пакеты. Если пользователь изменил пакет уже после сборки, изменится контрольная сумма.

vurdalak ★★★★★
() автор топика
Ответ на: комментарий от vurdalak

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

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.