34308 2017-12-10 18:14:07 +0300 rpm-build тянет поддержку различных языков и devel-пакеты 2024-09-11 20:21:53 +0300 1 1 4 Development Sisyphus rpm-build unstable all Linux CLOSED WONTFIX https://bugzilla.altlinux.org/show_bug.cgi?id=21608 P3 normal --- 1 lav placeholder arseny glebfm imz ldv mike placeholder vt qa-sisyphus oldest_to_newest 167791 0 lav 2017-12-10 18:14:07 +0300 rpm-build требует gcc, glibc-devel, но я не собираюсь ничего компилировать с языка C, все мои пакеты написаны на чистом shell. Представления о том, что программы пишутся на C, давно устарели. Нельзя ли рассмотреть возможность не тянуть лишнее? 167793 1 ldv 2017-12-10 18:15:42 +0300 (In reply to comment #0) > Представления о том, что программы пишутся на C, давно устарели. Программы пишутся на С. Всё, что не на С - это скрипты. :) 167795 2 ldv 2017-12-10 18:17:42 +0300 (In reply to comment #0) > Нельзя ли рассмотреть возможность не тянуть лишнее? Какую конкретную задачу хотите таким образом решить? Какую цену готовы за это заплатить? 167797 3 lav 2017-12-10 18:29:22 +0300 (В ответ на комментарий №2) > (In reply to comment #0) > > Нельзя ли рассмотреть возможность не тянуть лишнее? > > Какую конкретную задачу хотите таким образом решить? Не тянуть в систему возможность компилировать программы, это упрощает использование эксплоитов. Конкретно — тем, кто воспользуется перепаковкой rpm-пакета при установке: https://lists.altlinux.org/pipermail/devel/2017-December/203653.html > Какую цену готовы за это заплатить? Мне казалось, что этот вопрос уже обсуждали когда-то, но я не смог найти. Видимо, я о том, чтобы rpm-build не олицетворял собой минимальное сборочное окружение. Но я не умею торговаться. Просто скажите, сколько стоит :) Я так понимаю, проблема в том, что BuildRequires: gcc glibc-devel у нас подразумеваются, но не пишутся, а их доставка обеспечивается как раз этими зависимостями из rpm-build. 167895 4 mike 2017-12-13 04:55:01 +0300 (В ответ на комментарий №1) > > Представления о том, что программы пишутся на C, давно устарели. > Программы пишутся на С. Всё, что не на С - это скрипты. :) Некоторые считают, что на C++, и обеспечивают наличие g++ и libstdc++ в базовом сборочном окружении. На сейчас у нас некая серединка. 171523 5 lav 2018-06-02 12:48:04 +0300 (В ответ на комментарий №2) > (In reply to comment #0) > > Нельзя ли рассмотреть возможность не тянуть лишнее? > > Какую конкретную задачу хотите таким образом решить? > Какую цену готовы за это заплатить? Хотел бы повториться: я хотел бы иметь возможность собирать пакеты, не устанавливая для этого компилятор и библиотеки для C. 171524 6 ldv 2018-06-02 12:54:59 +0300 (In reply to comment #5) > (В ответ на комментарий №2) > > (In reply to comment #0) > > > Нельзя ли рассмотреть возможность не тянуть лишнее? > > > > Какую конкретную задачу хотите таким образом решить? > > Какую цену готовы за это заплатить? > > Хотел бы повториться: я хотел бы иметь возможность собирать пакеты, не > устанавливая для этого компилятор и библиотеки для C. А зачем? Какая от этого будет польза? В любом случае я бы не хотел для достижения этой цели ломать сборочную среду тысячам добропорядочных пакетов. 171525 7 lav 2018-06-02 13:48:29 +0300 (В ответ на комментарий №6) > (In reply to comment #5) > > (В ответ на комментарий №2) > > > (In reply to comment #0) > > > > Нельзя ли рассмотреть возможность не тянуть лишнее? > > > > > > Какую конкретную задачу хотите таким образом решить? > > > Какую цену готовы за это заплатить? > > > > Хотел бы повториться: я хотел бы иметь возможность собирать пакеты, не > > устанавливая для этого компилятор и библиотеки для C. > > А зачем? Какая от этого будет польза? epm --repack install сторонний.rpm перепаковывает указанный пакет с целью корректировки зависимостей стороннего пакета. Это нужно для установки проприетарных пакетов, которые бинарно совместимы, но не совпадают по зависимостям. Поскольку пересборка происходит в пользовательской системе, не хотелось бы туда тащить среду для сборки C-программ. > В любом случае я бы не хотел для достижения этой цели ломать сборочную среду > тысячам добропорядочных пакетов. Мне кажется, что установка базовых пакетов для сборки в hasher вполне может быть устроена без добавления зависимостей к rpm-build. Я же не предлагаю оторвать gcc от rpm-build, чтобы всё сломалось. Наверное, есть другое место, где можно добавить зависимости, предполагающие наличие gcc по умолчанию. 193318 8 lav 2020-10-18 09:23:53 +0300 Пакет rpm-build содержит команду rpmbuild и минимальное окружение для сборки пакета. Если пакет rpm-build каким-то образом попадает в сборочное окружение без его явного указания, то туда же можно добавить gcc glibc-devel autoconf automake rpm-build-perl rpm-build-python чтобы не ломать сборку. Но сам rpm-build я предлагаю очистить от этих странных зависимостей на старый python, на какой-то autoconf (я использую cmake), на perl (зачем перл для пакетов?? 193336 9 mike 2020-10-19 15:59:20 +0300 (Ответ для Vitaly Lipatov на комментарий #8) > (я использую cmake) А я не использую python. Полезный багрепорт содержал бы некий статанализ. 193337 10 mike 2020-10-19 16:01:25 +0300 (Ответ для Dmitry V. Levin на комментарий #6) > > Хотел бы повториться: я хотел бы иметь возможность собирать пакеты, > > не устанавливая для этого компилятор и библиотеки для C. > А зачем? Какая от этого будет польза? Ну и предложи патч с выносом rpm-build-base по существу и зависимостью от него в становящемся тогда метапакетом rpm-build. 193339 11 lav 2020-10-19 16:41:11 +0300 (Ответ для Michael Shigorin на комментарий #9) > (Ответ для Vitaly Lipatov на комментарий #8) > > (я использую cmake) > А я не использую python. Полезный багрепорт содержал бы некий статанализ. ... (Ответ для Michael Shigorin на комментарий #10) > (Ответ для Dmitry V. Levin на комментарий #6) > > > Хотел бы повториться: я хотел бы иметь возможность собирать пакеты, > > > не устанавливая для этого компилятор и библиотеки для C. > > А зачем? Какая от этого будет польза? > Ну и предложи патч с выносом rpm-build-base по существу и зависимостью от > него > в становящемся тогда метапакетом rpm-build. Нет, у меня другая позиция: rpm-build создаёт окружение для сборки пакетов, то есть для выполнения команды rpmbuild -bb Я не нашёл иной трактовки и традиции. В Fedora, например, rpm-build не тянет gcc, perl, python, ocaml, node и glibc-devel Добавление к этому пакету разных левых зависимостей было ошибкой, которую нужно исправить. И если кому-то нужен пакет, который поставит какие-то базовые инструменты для сборки программ (autotools, perl, python, gcc), то такой пакет и надо сделать. Тут видимо было смешение смыслов понятия «сборочная среда» — для пакетов она или для сборки программ с помощью autotools. 193684 12 lav 2020-11-01 05:36:18 +0300 Было и противоположное предложение: https://bugzilla.altlinux.org/show_bug.cgi?id=25600 193816 13 ldv 2020-11-06 02:13:53 +0300 В последнее время в Федоре активно выпиливают традиционные пакеты из базовой сборочной среды. Очередная инициатива оттуда - выпилить make, см. https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot Обоснования таких изменений у них стереотипные: "Removing make from the BuildRoot will reduce the network traffic, download times, and disk usage for these builds in Koji and also for users doing builds with mock." На самом деле преимущества выпиливания пакетов из базовой сборочной среды неочевидны. Даже если пренебречь большими расходами на адаптацию спек-файлов, в каждом конкретном случае нужно посчитать и сравнить плюсы и минусы. Плюс присутствия пакета в базовой сборочной среде один, но он большой: поскольку образ базовой сборочной среды закэширован, установка пакета в составе базовой сборочной среды на порядки эффективнее как по времени, так и по сетевому трафику. Минусы присутствия пакета в базовой сборочной среде: - занимает место, даже когда не используется; - обновление такого пакета вызывает обновление образа базовой сборочной среды; - невозможно достоверно установить, что такой пакет не используется для сборки. Когда пакет из базовой сборочной среды на самом деле используется для сборки большого числа пакетов, то плюс перевешивает минусы. Точнее можно сказать, сравнив, например, суммарное время сборки всех пакетов в обоих вариантах базовой сборочной среды. 193881 14 lav 2020-11-07 21:20:39 +0300 (Ответ для Dmitry V. Levin на комментарий #13) ... > На самом деле преимущества выпиливания пакетов из базовой сборочной среды ... Дмитрий, мы говорим о разном. Ваш аргумент о базовой сборочной среде бесспорен. Более того, если это имеет эффект, её можно и расширять, чтобы она покрыла самые частые случаи и была действительно базовой. Но я говорю о том, что было ошибкой устраивать, чтобы rpm-build вытягивал базовую сборочную среду. Моё предложение в том, чтобы очистить rpm-build и оставить его тем, чем он является — базовой средой для сборки rpm-пакета. И добавить rpm-build-base, который и будет вытягивать базовую сборочную среду (мета-пакет с зависимостями). Безусловно, создавать базовую сборочную среду, используя пакет rpm-build-base, а не пакет rpm-build, труда не составит. 193882 15 ldv 2020-11-07 21:39:21 +0300 (In reply to Vitaly Lipatov from comment #14) > Безусловно, создавать базовую сборочную среду, используя пакет > rpm-build-base, а не пакет rpm-build, труда не составит. Для этого надо найти все места, где rpm-build используется для порождения базовой сборочной среды, и заменить его на какое-то другое имя. Помимо pkg_build_list в hasher, про который все помнят, есть, наверное, и другие места, например, какие-то профили создания образов, которые не так просто найти. 193884 16 lav 2020-11-07 22:04:00 +0300 (Ответ для Dmitry V. Levin на комментарий #15) > (In reply to Vitaly Lipatov from comment #14) > > Безусловно, создавать базовую сборочную среду, используя пакет > > rpm-build-base, а не пакет rpm-build, труда не составит. > > Для этого надо найти все места, где rpm-build используется для порождения > базовой сборочной среды, и заменить его на какое-то другое имя. > > Помимо pkg_build_list в hasher, про который все помнят, есть, наверное, и > другие места, например, какие-то профили создания образов, которые не так > просто найти. Я так понимаю, что образы, которые собирают базовую сборочную систему, это достаточно редкая птица. И mkimage-профайлы кучкуются по каким-то репозиториям, в которых доступен grep. Есть же специалисты, которые всё время с ними работают, наверное, они легко найдут и исправят, если это вызовет проблему. Не хотелось бы оставлять смысл и назначение пакета rpm-build не таким, как это принято в rpm-мире. Конечно, решение задачи требует определённых усилий, тут не следует менять задачу до тех пор, пока стоимость её решения не станет нулевой (её не нужно будет решать). Если тяжесть решения ложится на инициатора, я готов поработать в заданном направлении. 193885 17 mike 2020-11-07 22:19:45 +0300 (Ответ для Vitaly Lipatov на комментарий #16) > > Помимо pkg_build_list в hasher, про который все помнят, есть, наверное, > > и другие места, например, какие-то профили создания образов, которые не > > так просто найти. > Я так понимаю, что образы, которые собирают базовую сборочную систему, > это достаточно редкая птица. И mkimage-профайлы кучкуются по каким-то > репозиториям, в которых доступен grep. В mkimage не применяется --pkg-build-list (в явном виде и без вариантов передаётся пустой); --pkg-init-list по умолчанию инициализируется пустым, но это конфигурируемо при помощи переменной IMAGE_INIT_LIST. Видимо, понадобится пройти по спискам пакетов, содержащим rpm-build, и поправить их; в m-p таких мест больше, чем хотелось бы, но тоже обозримо: pkg.in/lists/centaurus/cluster pkg.in/lists/centaurus/disk-server-light pkg.in/lists/dev/builder pkg.in/lists/education/base pkg.in/lists/tagged/base+builder pkg.in/lists/tagged/builder+extra pkg.in/lists/tagged/main+builder Про m-p-d, видимо, уже не стоит беспокоиться, а создатели обособленных профилей обычно более чем компетентны в вопросах того, что именно хотят там видеть. 193887 18 lav 2020-11-07 22:29:39 +0300 (Ответ для Michael Shigorin на комментарий #17) > (Ответ для Vitaly Lipatov на комментарий #16) > > > Помимо pkg_build_list в hasher, про который все помнят, есть, наверное, > > > и другие места, например, какие-то профили создания образов, которые не > > > так просто найти. > > Я так понимаю, что образы, которые собирают базовую сборочную систему, > > это достаточно редкая птица. И mkimage-профайлы кучкуются по каким-то > > репозиториям, в которых доступен grep. > > В mkimage не применяется --pkg-build-list (в явном виде и без вариантов > передаётся пустой); --pkg-init-list по умолчанию инициализируется пустым, > но это конфигурируемо при помощи переменной IMAGE_INIT_LIST. > > Видимо, понадобится пройти по спискам пакетов, содержащим rpm-build, > и поправить их; в m-p таких мест больше, чем хотелось бы, но тоже обозримо: > pkg.in/lists/centaurus/cluster > pkg.in/lists/centaurus/disk-server-light > pkg.in/lists/dev/builder > pkg.in/lists/education/base > pkg.in/lists/tagged/base+builder > pkg.in/lists/tagged/builder+extra > pkg.in/lists/tagged/main+builder Тут в ряде случаев указан rpm-build в качестве необходимого пакета для hasher, в других местах он символизирует сборочную среду (не думаю, что имеющую в виду сборку именно rpm-пакетов). В идеале бы сделать пакет для базовой сборочной среды не зависящим от rpm-build. 194473 19 lav 2020-11-26 00:53:54 +0300 Также пакет базовой сборочной среды можно назвать build-essential, чтобы иметь совместимость с Debian. Если будет принято другое название, то просьба добавить такой provides. 196586 20 lav 2021-02-28 15:55:49 +0300 Может быть, с этой задачей нужна помощь? Предлагаю сделать изменение в три шага: 1.1. Определиться с названием пакета build-essential. 1.2. Вынести зависимости из rpm-build в build-essential, проставив в rpm-build зависимость на build-essential. 2. В сборочных системах добавить, где надо, зависимость на build-essential. 3. Убрать из rpm-build зависимость на build-essential. 202211 21 lav 2021-09-02 02:23:25 +0300 Предложил такую схему: Всё, что требует сборки программ, то есть проектов с компиляцией, вписано в зависимости метапакета rpm-build-gcc. rpm-build-slim — это бинарная перепаковка пакета rpm-build, с исправлением зависимостей (убрано то, что уехало в rpm-build-gcc). Предполагается, что содержимое пакетов rpm-build и rpm-build-slim всегда идентично и они не могут расходиться по версиям. 284378 TESTED #2 [test-only] sisyphus rpm-build-gcc.git=10.0-alt1 rpm-build-slim.git=4.0.4-alt177 251535 22 lav 2024-09-11 19:18:29 +0300 Для сборки без rpm-build, тянущего сборочную среду, предложен пакет eepm-rpm-build (практически ванильный rpm-build), не имеющих лишних зависимостей, кроме как нужных для сборки rpm-пакета. 251536 23 lav 2024-09-11 19:18:30 +0300 Для сборки без rpm-build, тянущего сборочную среду, предложен пакет eepm-rpm-build (практически ванильный rpm-build), не имеющих лишних зависимостей, кроме как нужных для сборки rpm-пакета. 251542 24 mike 2024-09-11 20:21:53 +0300 (Ответ для Dmitry V. Levin на комментарий #15) > (In reply to Vitaly Lipatov from comment #14) > > Безусловно, создавать базовую сборочную среду, используя пакет > > rpm-build-base, а не пакет rpm-build, труда не составит. > > Для этого надо найти все места, где rpm-build используется для порождения > базовой сборочной среды, и заменить его на какое-то другое имя. > > Помимо pkg_build_list в hasher, про который все помнят, есть, наверное, и > другие места, например, какие-то профили создания образов, которые не так > просто найти. Других мест сходу и не соображу, а эти два поправить достаточно просто. (сейчас вспомнили по той причине, что eepm-rpm-build не собирается в лоб на e2k, поскольку http://lists.rpm.org/pipermail/rpm-maint/2016-March/004214.html)