Исправление ZenitharChampion, (текущая версия) :
А я считаю, что случай - показательный, и применимый к Debian тоже. Во-первых, никто не мешает принять патчик, фиксящий сборку на старых системах - кому он мешает? Во-вторых:
В новых версиях openSUSE можно не использовать в spec-файле - строку BuildRoot:, а в разделе %files - строку %defattr(-,root,root). Spec-файл при этом будет корректен.
Однако для ряде _ключевых_ пакетов, эти строки всё ещё присутствуют - посмотри например GCC 9. Их там не может не быть, потому, что SLES 11 (как и RHEL) используется в кровавом энтерпрайзе, где длительный срок поддержки ОС является ключевым фактором в её выборе. А GCC (как и cmake) это такое ПО, которое этим самым кровавым энтерпрайзом используется. Я не думаю, что они собирают своё корпоративное ПО старым компилятором GCC 4.3/4.4. У RHEL например есть devtoolset. Cmake в нём вроде нет.
Всё было так, пока не пришёл этот хипстер, который тупо прошёлся по всем пакетам, и не поубирал оттуда BuildRoot:. На возражения он ответил «ко-ко-ко говно мамонта азаза давно пора». Ну и убирал бы BuildRoot: в GNOME3, NetworkManager, Amarok - в общем, во всём том, что в старые (но поддерживаемые) системы точно никто не потащит. Но не лез бы в системное ПО.
В cmake всё как надо на самом деле - BuildRoot: на месте. Проблема в том, что в версии 3.8 добавили зависимость от rhash, а пакет с rhash создал вышеобозначенный хипстер.
Что касается Debian. Новые правила, которые были приняты в результате голосования, оставляют поддержку SysVinit на совесть мейнтейнера. Теперь он так же может взять и удалить init-скрипты. Даже не отказаться написать init-скрипт для нового пакета - а удалить уже написанное и работающее, как вышеобозраченный хипстер (он также был замечен за тем, что потёр в куче пакетов - возможность сборки с обеими версиями Python). А на все возражения - ссылаться на новое правило, мол «я могу захотеть оставить правило init, а могу удалить, и никто мне ничего не сделает».
Исходная версия ZenitharChampion, :
А я считаю, что случай - показательный, и применимый к Debian тоже. Во-первых, никто не мешает принять патчик, фиксящий сборку на старых системах - кому он мешает? Во-вторых:
В новых версиях openSUSE можно не использовать в spec-файле - строку Однако для ряде _ключевых_ пакетов, эти строки всё ещё присутствуют - посмотри например GCC 9. Их там не может не быть, потому, что SLES 11 (как и RHEL) используется в кровавом энтерпрайзе, где длительный срок поддержки ОС является ключевым фактором в её выборе. А GCC (как и cmake) это такое ПО, которое этим самым кровавым энтерпрайзом используется. Я не думаю, что они собирают своё корпоративное ПО старым компилятором GCC 4.3/4.4. У RHEL например есть devtoolset. Cmake в нём вроде нет. Всё было так, пока не пришёл этот хипстер, который тупо прошёлся по всем пакетам, и не поубирал оттуда В cmake всё как надо на самом деле - Что касается Debian. Новые правила, которые были приняты в результате голосования, оставляют поддержку SysVinit на совесть мейнтейнера. Теперь он так же может взять и удалить init-скрипты. Даже не отказаться написать init-скрипт для нового пакета - а удалить уже написанное и работающее, как вышеобозраченный хипстер (он также был замечен за тем, что потёр в куче пакетов - возможность сборки с обеими версиями Python). А на все возражения - ссылаться на новое правило, мол «я могу захотеть оставить правило init, а могу удалить, и никто мне ничего не сделает».BuildRoot:, а в разделе %files[.inline] - строку . Spec-файл при этом будет корректен.%defattr(-,root,root)BuildRoot:. На возражения он ответил «ко-ко-ко говно мамонта азаза давно пора». Ну и убирал бы BuildRoot: в GNOME3, NetworkManager, Amarok - в общем, во всём том, что в старые (но поддерживаемые) системы точно никто не потащит. Но не лез бы в системное ПО.BuildRoot: на месте. Проблема в том, что в версии 3.8 добавили зависимость от rhash, а пакет с rhash создал вышеобозначенный хипстер.