Bug 34308 - rpm-build requires gcc, glibc-devel
: rpm-build requires gcc, glibc-devel
Status: NEW
: Sisyphus
(All bugs in Sisyphus/rpm-build)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2017-12-10 18:14 by
Modified: 2018-06-02 13:48 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2017-12-10 18:14:07
rpm-build требует gcc, glibc-devel,
но я не собираюсь ничего компилировать с языка C,
все мои пакеты написаны на чистом shell.

Представления о том, что программы пишутся на C, давно устарели.

Нельзя ли рассмотреть возможность не тянуть лишнее?
------- Comment #1 From 2017-12-10 18:15:42 -------
(In reply to comment #0)
> Представления о том, что программы пишутся на C, давно устарели.

Программы пишутся на С.  Всё, что не на С - это скрипты. :)
------- Comment #2 From 2017-12-10 18:17:42 -------
(In reply to comment #0)
> Нельзя ли рассмотреть возможность не тянуть лишнее?

Какую конкретную задачу хотите таким образом решить?
Какую цену готовы за это заплатить?
------- Comment #3 From 2017-12-10 18:29:22 -------
(В ответ на комментарий №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.
------- Comment #4 From 2017-12-13 04:55:01 -------
(В ответ на комментарий №1)
> > Представления о том, что программы пишутся на C, давно устарели.
> Программы пишутся на С.  Всё, что не на С - это скрипты. :)
Некоторые считают, что на C++, и обеспечивают наличие g++ и libstdc++
в базовом сборочном окружении.  На сейчас у нас некая серединка.
------- Comment #5 From 2018-06-02 12:48:04 -------
(В ответ на комментарий №2)
> (In reply to comment #0)
> > Нельзя ли рассмотреть возможность не тянуть лишнее?
> 
> Какую конкретную задачу хотите таким образом решить?
> Какую цену готовы за это заплатить?

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

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

В любом случае я бы не хотел для достижения этой цели ломать сборочную среду
тысячам добропорядочных пакетов.
------- Comment #7 From 2018-06-02 13:48:29 -------
(В ответ на комментарий №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
по умолчанию.