Уважаемые мейнтейнеры binutils!

Пожалуйста, напишите, как вы относитесь к этой задаче. Стоит ли мне ожидать, что такое и/или подобное изменение будет сделано в binutils (а также gcc и glibc) или мне нужно идти другим путём? Если стóит, то могу ли я что-то сделать чтобы приблизить этот момент?

Спасибо.

(In reply to Ivan A. Melnikov from comment #0)
> В связи с этим я предлагаю запаковать исходники такими, какими они
> получились в результате работы секции %pre, например так:

Мне нравится это предложение.

> http://git.altlinux.org/people/iv/packages/binutils.git?a=commit;
> h=e66b62761d439e9cf8ed5ef7bd9b6467629858da

По технике: у tar есть параметр -C.

(In reply to Dmitry V. Levin from comment #2)
> > http://git.altlinux.org/people/iv/packages/binutils.git?a=commit;
> > h=e66b62761d439e9cf8ed5ef7bd9b6467629858da
> 
> По технике: у tar есть параметр -C.

Я хотел им воспользоваться, но он не влияет на путь к архиву (аргумент -f):

$ mkdir test
$ cd test
$ touch a.txt
$ tar -C.. -cf t.tar test
tar: test/t.tar: file is the archive; not dumped
$ ls
a.txt  t.tar
$ tar -tf t.tar
test/
test/a.txt

Можно конечно указать -cf "../%name-%version-%release.tar" или вычислить польный путь, но вариант с со сменой каталога показался мне более простым и понятным.

Я был почему-то уверен, что патчи сейчас упакованы в пакет.

Идея была в том, что некоторые патчи не стоит прикладывать на каких-то архитектурах.  gnu.hash в binutils (сейчас мы его включаем через configure, но раньше это был патч, который на mips *не прикладывался*) и stack-protector в gcc не поддерживаются на некоторых архитектурах.  (В glibc таких патчей нет и скорее всего не будет никогда, к тому же все наши патчи и так применены в tarball-е, который лежит в glibc-source.)

Применение таких патчей в архиве значило бы, что на таких архитектурах нужно всё равно приносить эти патчи с собой, чтобы их *откатить*.  Мы точно хотим именно этого?  Не разумнее ли положить патчи в пакет и для большей части архитектур сделать autopatch или его аналог в cross-toolchain?

(In reply to Gleb F-Malinovskiy from comment #4)
> В glibc таких патчей нет и скорее всего не будет никогда,
> к тому же все наши патчи и так применены в tarball-е,
> который лежит в glibc-source.

Да, в glibc в этом плане уже всё хорошо. Мне бы хотелось лишь зафиксировать пожелание, чтобы оно так и оставалось в следующих сборках.

> Применение таких патчей в архиве значило бы, что на таких архитектурах нужно
> всё равно приносить эти патчи с собой, чтобы их *откатить*.  Мы точно хотим
> именно этого?

Да. *Если* такие патчи снова появятся.

> Не разумнее ли положить патчи в пакет и для большей части
> архитектур сделать autopatch или его аналог в cross-toolchain?

Я не придумал аналога autopatch, который бы учитывал разный порядок патчей,  разные -p в %patchN и, например, sed'а который был в binutils 2.35. 

А ещё нравится идея того, что "binutils-source -- это те исходники, из которых мы собрали binutils, и делайте с ними что хотите". Я, как ответсвенный за тулчейн на mipsel и riscv64 (и некроссового тоже), знаю, что я хочу с ними сделать. А вот проверять при каждом обновлении, правильно ли я применил все нужные патчи, как-то слишком tedious и error-prone.

(In reply to Gleb F-Malinovskiy from comment #4)
> Я был почему-то уверен, что патчи сейчас упакованы в пакет.
> 
> Идея была в том, что некоторые патчи не стоит прикладывать на каких-то
> архитектурах.  gnu.hash в binutils (сейчас мы его включаем через configure,
> но раньше это был патч, который на mips *не прикладывался*) и
> stack-protector в gcc не поддерживаются на некоторых архитектурах.  (В glibc
> таких патчей нет и скорее всего не будет никогда, к тому же все наши патчи и
> так применены в tarball-е, который лежит в glibc-source.)

На мой взгляд, пакет binutils выиграл бы от перехода на ту схему сопровождения патчей,
которая сейчас используется в пакете glibc.
На самом деле эта схема в том или ином виде и так уже используется "под капотом".
В качестве побочного эффекта вопрос с binutils-source решился бы сам собой.

(In reply to Ivan A. Melnikov from comment #5)
> (In reply to Gleb F-Malinovskiy from comment #4)
> > В glibc таких патчей нет и скорее всего не будет никогда,
> > к тому же все наши патчи и так применены в tarball-е,
> > который лежит в glibc-source.
> 
> Да, в glibc в этом плане уже всё хорошо. Мне бы хотелось лишь зафиксировать
> пожелание, чтобы оно так и оставалось в следующих сборках.
> 
> > Применение таких патчей в архиве значило бы, что на таких архитектурах нужно
> > всё равно приносить эти патчи с собой, чтобы их *откатить*.  Мы точно хотим
> > именно этого?
> 
> Да. *Если* такие патчи снова появятся.

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

> > Не разумнее ли положить патчи в пакет и для большей части
> > архитектур сделать autopatch или его аналог в cross-toolchain?
> 
> Я не придумал аналога autopatch, который бы учитывал разный порядок патчей, 
> разные -p в %patchN и, например, sed'а который был в binutils 2.35. 
> 
> А ещё нравится идея того, что "binutils-source -- это те исходники, из
> которых мы собрали binutils, и делайте с ними что хотите". Я, как
> ответсвенный за тулчейн на mipsel и riscv64 (и некроссового тоже), знаю, что
> я хочу с ними сделать. А вот проверять при каждом обновлении, правильно ли я
> применил все нужные патчи, как-то слишком tedious и error-prone.

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

(In reply to Dmitry V. Levin from comment #6)
> На мой взгляд, пакет binutils выиграл бы от перехода на ту схему
> сопровождения патчей,
> которая сейчас используется в пакете glibc.
> На самом деле эта схема в том или ином виде и так уже используется "под
> капотом".
> В качестве побочного эффекта вопрос с binutils-source решился бы сам собой.

Согласен.  Да в общем-то понятно, что и в случае gcc можно применить этот же подход, у gcc даже апстрим уже в git-е наконец. :)

(In reply to Gleb F-Malinovskiy from comment #7)
> (In reply to Ivan A. Melnikov from comment #5)
> > (In reply to Gleb F-Malinovskiy from comment #4)
> > > Применение таких патчей в архиве значило бы, что на таких архитектурах нужно
> > > всё равно приносить эти патчи с собой, чтобы их *откатить*.  Мы точно хотим
> > > именно этого?
> > 
> > Да. *Если* такие патчи снова появятся.
> 
> Это неизбежно случится, если мы захотим собрать кросс-тулчейн для
> архитектур, которые у нас не поддерживаются, среди них есть разная степень
> поддержки некоторых функций.

Такие архитекуры не принципиально синхронизировать с тулчейном Сизифа (или соответствующего бранча); использование для них gcc-source/binutils-source/glibc-source не кажется мне оправданным. У меня, например, были бы немного другие пожелания к кросс-тулчейну если бы полученные бинарники не должны бы были работать в Альте.

(In reply to Ivan A. Melnikov from comment #8)
> Такие архитекуры не принципиально синхронизировать с тулчейном Сизифа (или
> соответствующего бранча); использование для них
> gcc-source/binutils-source/glibc-source не кажется мне оправданным. У меня,
> например, были бы немного другие пожелания к кросс-тулчейну если бы
> полученные бинарники не должны бы были работать в Альте.

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

binutils-1:2.37-alt2 -> sisyphus:

 Wed Sep 29 2021 Gleb F-Malinovskiy <glebfm@altlinux> 1:2.37-alt2
 - Changed build scheme to git branches instead of patches (ALT#40904).
 - Fixed preserving dates in ar archives processed with strip/objcopy
   with -p/--preserve-dates option.
 - Fixed FTBFS with gcc 11 (by switching some test back to DWARF version 4).