(In reply to comment #0)
> Представления о том, что программы пишутся на C, давно устарели.

Программы пишутся на С.  Всё, что не на С - это скрипты. :)

(In reply to comment #0)
> Нельзя ли рассмотреть возможность не тянуть лишнее?

Какую конкретную задачу хотите таким образом решить?
Какую цену готовы за это заплатить?

(В ответ на комментарий №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.

(В ответ на комментарий №1)
> > Представления о том, что программы пишутся на C, давно устарели.
> Программы пишутся на С.  Всё, что не на С - это скрипты. :)
Некоторые считают, что на C++, и обеспечивают наличие g++ и libstdc++
в базовом сборочном окружении.  На сейчас у нас некая серединка.

(В ответ на комментарий №2)
> (In reply to comment #0)
> > Нельзя ли рассмотреть возможность не тянуть лишнее?
> 
> Какую конкретную задачу хотите таким образом решить?
> Какую цену готовы за это заплатить?

Хотел бы повториться: я хотел бы иметь возможность собирать пакеты, не устанавливая для этого компилятор и библиотеки для C.

(In reply to comment #5)
> (В ответ на комментарий №2)
> > (In reply to comment #0)
> > > Нельзя ли рассмотреть возможность не тянуть лишнее?
> > 
> > Какую конкретную задачу хотите таким образом решить?
> > Какую цену готовы за это заплатить?
> 
> Хотел бы повториться: я хотел бы иметь возможность собирать пакеты, не
> устанавливая для этого компилятор и библиотеки для C.

А зачем?  Какая от этого будет польза?

В любом случае я бы не хотел для достижения этой цели ломать сборочную среду тысячам добропорядочных пакетов.

(В ответ на комментарий №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 по умолчанию.

Пакет rpm-build содержит команду rpmbuild и минимальное окружение для сборки пакета.

Если пакет rpm-build каким-то образом попадает в сборочное окружение без его явного указания, то туда же можно добавить
gcc
glibc-devel
autoconf
automake
rpm-build-perl
rpm-build-python

чтобы не ломать сборку. Но сам rpm-build я предлагаю очистить от этих странных зависимостей на старый python, на какой-то autoconf (я использую cmake), на perl (зачем перл для пакетов??

(Ответ для Vitaly Lipatov на комментарий #8)
> (я использую cmake)
А я не использую python.  Полезный багрепорт содержал бы некий статанализ.

(Ответ для Dmitry V. Levin на комментарий #6)
> > Хотел бы повториться: я хотел бы иметь возможность собирать пакеты,
> > не устанавливая для этого компилятор и библиотеки для C.
> А зачем?  Какая от этого будет польза?
Ну и предложи патч с выносом rpm-build-base по существу и зависимостью от него
в становящемся тогда метапакетом rpm-build.

(Ответ для 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.

Было и противоположное предложение:
https://bugzilla.altlinux.org/show_bug.cgi?id=25600

В последнее время в Федоре активно выпиливают традиционные пакеты из базовой сборочной среды.  Очередная инициатива оттуда - выпилить 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."

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

Плюс присутствия пакета в базовой сборочной среде один, но он большой:
поскольку образ базовой сборочной среды закэширован, установка пакета в составе базовой сборочной среды на порядки эффективнее как по времени, так и по сетевому трафику.

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

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

(Ответ для Dmitry V. Levin на комментарий #13)
...
> На самом деле преимущества выпиливания пакетов из базовой сборочной среды
...
Дмитрий, мы говорим о разном. Ваш аргумент о базовой сборочной среде бесспорен.
Более того, если это имеет эффект, её можно и расширять, чтобы она покрыла самые частые случаи и была действительно базовой.

Но я говорю о том, что было ошибкой устраивать, чтобы rpm-build вытягивал базовую сборочную среду.

Моё предложение в том, чтобы очистить rpm-build и оставить его тем, чем он является — базовой средой для сборки rpm-пакета.

И добавить rpm-build-base, который и будет вытягивать базовую сборочную среду (мета-пакет с зависимостями).

Безусловно, создавать базовую сборочную среду, используя пакет rpm-build-base, а не пакет rpm-build, труда не составит.

(In reply to Vitaly Lipatov from comment #14)
> Безусловно, создавать базовую сборочную среду, используя пакет
> rpm-build-base, а не пакет rpm-build, труда не составит.

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

Помимо pkg_build_list в hasher, про который все помнят, есть, наверное, и другие места, например, какие-то профили создания образов, которые не так просто найти.

(Ответ для 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-мире.

Конечно, решение задачи требует определённых усилий, тут не следует менять задачу до тех пор, пока стоимость её решения не станет нулевой (её не нужно будет решать). Если тяжесть решения ложится на инициатора, я готов поработать в заданном направлении.

(Ответ для 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, видимо, уже не стоит беспокоиться, а создатели обособленных профилей обычно более чем компетентны в вопросах того, что именно хотят там видеть.

(Ответ для 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.

Также пакет базовой сборочной среды можно назвать build-essential, чтобы иметь совместимость с Debian.
Если будет принято другое название, то просьба добавить такой provides.

Может быть, с этой задачей нужна помощь?

Предлагаю сделать изменение в три шага:
1.1. Определиться с названием пакета build-essential.
1.2. Вынести зависимости из rpm-build в build-essential, проставив в rpm-build зависимость на build-essential.
2. В сборочных системах добавить, где надо, зависимость на build-essential.
3. Убрать из rpm-build зависимость на build-essential.

Предложил такую схему:
Всё, что требует сборки программ, то есть проектов с компиляцией, вписано в зависимости метапакета 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

Для сборки без rpm-build, тянущего сборочную среду, предложен пакет eepm-rpm-build (практически ванильный rpm-build), не имеющих лишних зависимостей, кроме как нужных для сборки rpm-пакета.

Для сборки без rpm-build, тянущего сборочную среду, предложен пакет eepm-rpm-build (практически ванильный rpm-build), не имеющих лишних зависимостей, кроме как нужных для сборки rpm-пакета.

(Ответ для 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)