Какую именно архитектуру нужно писать в поле Architecture при сборке пакетов из исходников?

[жучара]

Друзья! Собираю бинарник из исходников. Есть файл debian/control
https://www.debian.org/doc/debian-policy/ch-controlfields.html

А в нём поле Architecture
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-architecture

В это поле нужно написать какую-нибудь архитектуру
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-spec
и пакет соберётся. Список архитектур брать так
dpkg-architecture -L

++++++++++++++++++++++++++++++++++++++++++++++++++++

Пакет будет минимальный. Лишь бы был.

Это вот будет папка с исходниками

Shell

mkdir heh-1

Это вот архив создадим, так положено

Shell

tar -cvzf heh-1.tar.gz heh-1

Так создадим *orig* файл и папку debian

Shell

cd heh-1
dh_make -s -y -f ../heh-1.tar.gz

Теперь поправим файл debian/control. Архитектуру возьмём из списка dpkg-architecture -L какую-нибудь. Например, or1k

cat debian/control

Source: heh
Section: main
Priority: optional
Maintainer: unknown <use@astra>
Build-Depends: debhelper (>= 9)
Standards-Version: 3.9.8
Homepage: <insert the upstream URL, if relevant>
#Vcs-Git: https://anonscm.debian.org/collab-maint/heh.git
#Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/heh.git

Package: heh
Architecture: or1k
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: <insert up to 60 chars description>
<insert long description, indented with spaces>

Зачем-то кропаем файлы heh_1-1.debian.tar.xz и heh_1-1.dsc:

Shell

cd ..
dpkg-source -b heh-1

Кропаем файл *.deb

Shell

$ cd heh-1
use@astra:~/Desktop/foo/heh-1$ fakeroot debian/rules binary
dh binary
dh: No packages to build.

Ничё не выходит. А не выходит потому, что в Architecture нужно писать не абы какую строку. А какие именно строки писать- не понять (подходит, например, amd64, но угадывание не наш метод.). Вот тот и вопрос, что именно нужно писать сюда и чем руководствоваться. Пункт
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-architecture
Я прочёл полностью, никаких ограничений я там не нашёл на этот счёт. Спасибо, кто откликнется. Астралинукс Орёл 2.12

[Bizdelnick]

any для архитектурозависимого пакета, all для архитектуронезависимого.
И не надо опять лгать, что этого не написано по Вашим ссылкам.

[жучара]

any для архитектурозависимого пакета, all для архитектуронезависимого.
И не надо опять лгать, что этого не написано по Вашим ссылкам.

но меня-то не интересует any или all, а только для конкретной архитектуры. or1k в качестве примера. Вопрос открыт.

[Bizdelnick]

Вопрос открыт.

Вы, такой шалунишка, снова лжёте. Ответ дан, вопрос закрыт.

[Rootlexx]

но меня-то не интересует any или all, а только для конкретной архитектуры.

any в процессе сборки и превратится в конкретную архитектуру.

[жучара]

но меня-то не интересует any или all, а только для конкретной архитектуры.

any в процессе сборки и превратится в конкретную архитектуру.

нет. Когда я написал any, у меня собралось heh_1-1_amd64.deb, а должно было heh_1-1_or1k.deb

[Rootlexx]

нет. Когда я написал any, у меня собралось heh_1-1_amd64.deb, а должно было heh_1-1_or1k.deb

Почему "нет"? Указали any - превратилось в конкретную архитектуру amd64. Что не так?

amd64 - это архитектура вашей системы, на которой вы собираете. Если вы хотите собрать пакет для другой архитектуры, то её следует указать при сборке (опция -a у dpkg-buildpackage, например). См. также: https://wiki.debian.org/CrossCompiling

[жучара]

Rootlexx, да, но тогда возникают другие вопросы ещё более непонятные тык скыть. И первый из них. Оставим пока в сторонке вариант, предложенный вами, и сосредоточимся на том, что писать в поле Architecture (в сырцах, в файле debian/control)

Тут читаем
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-architecture

In the main debian/control file in the source package, this field may contain the special value all, the special architecture wildcard any, or a list of specific and wildcard architectures separated by spaces. If all or any appears, that value must be the entire contents of the field. Most packages will use either all or any.

Ну то есть можно туда писать помимо all и any какой-то

list of specific and wildcard architectures separated by spaces

Я вообще не пойму что это такое, список определённых и подстановочных архитектур. Да хрен с ним, со списком, вопрос- где его взять? А вот выше:

"A unique single word identifying a Debian machine architecture as described in Architecture specification strings."

То есть определённые архитектуры берём тут
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-spec

dpkg-architecture -L

и неуспешно. Если я должен туда писать (помимо разрешённых all и any), только мою архитектуру, amd64- так они же так не написали. Нет, они написали, берите из списка и вставляйте. Вот вставил и ничё не получается. Непонятно.

[Bizdelnick]

ТС написал:

Какую именно архитектуру нужно писать в поле Architecture при сборке пакетов из исходников?

А оказывается, ему вовсе не это нужно, а собрать пакет под определённую архитектуру. Кругом ложь. Грустно.

[жучара]

ТС написал:

Какую именно архитектуру нужно писать в поле Architecture при сборке пакетов из исходников?

А оказывается, ему вовсе не это нужно, а собрать пакет под определённую архитектуру. Кругом ложь. Грустно.

всё правильно я спросил.

[Bizdelnick]

всё правильно я спросил.

Где же правильно? Налицо подмена понятий. Ну или XY-проблема. Но кого это волнует, все должны догадаться, о чём думал ТС.

[Rootlexx]

Вот вставил и ничё не получается. Непонятно.

Что ж тут непонятного? Вы вписали для пакета архитектуру or1k, затем выполнили команду сборки безо всяких указаний архитектуры - получили сборку для архитектуры по умолчанию, которой является основная архитектура вашей системы (amd64). А для данной архитектуры пакетов для сборки нет (or1k ≠ amd64), о чём вам и сказано в выводе команды.

[жучара]

всё правильно я спросил.

Где же правильно? Налицо подмена понятий. Ну или XY-проблема. Но кого это волнует, все должны догадаться, о чём думал ТС.

а что конкретно вам непонятно? Я, по-моему, всё объяснил, может, что упустил, хз.

[жучара]

Вот вставил и ничё не получается. Непонятно.

Что ж тут непонятного? Вы вписали для пакета архитектуру or1k, затем выполнили команду сборки безо всяких указаний архитектуры - получили сборку для архитектуры по умолчанию, которой является основная архитектура вашей системы (amd64). А для данной архитектуры пакетов для сборки нет (or1k ≠ amd64), о чём вам и сказано в выводе команды.

то есть я раз указал or1k, мало, надо ещё второй раз указывать. Ладно. А тогда ещё вопрос c вашего позволения:

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-architecture

Specifying only all indicates that the source package will only build architecture-independent packages.

Тогда если мы напишем в это поле all- всё, никаких ограничений. Действительно создастся файл heh_1-1_all.deb, внутри которого будет файл control, где действительно будет написано:
Architecture: all
Что предполагает, естессно, и or1k и всю те 524 архитектуры что выводятся по команде:
dpkg-architecture -L

То есть мысль та, что под одну архитектуру (которая не по умолчанию) так просто *.deb файл не скропать. А под все пожалуйста. Так ли это?

[Rootlexx]

то есть я раз указал or1k, мало, надо ещё второй раз указывать

В файле control содержатся описания пакетов. Указав там архитектуру or1k, вы лишь указали, что данное описание пакета относится к архитектуре or1k.
Пусть есть:

Код: Выделить всё

Package: somepackage-amd64
Architecture: amd64
Description: somepackage for amd64

Package: somepackage-or1k
Architecture: or1k
Description: somepackage for or1k

Package: somepackage-any
Architecture: any
Description: somepackage for any architecture

Тогда при сборке для архитектуры amd64 будет собран пакет somepackage-amd64, а при сборке для or1k - пакет somepackage-or1k. И в обоих случаях будет собран пакет somepackage-any.
Т.е. поле Architecture не задаёт архитектуру сборки, а лишь указывает, что данное описание активно только при сборке для данной архитектуры, и для других архитектур не используется. Можете понимать его как "MatchArchitecture".
Для какой же архитектуры собирать пакеты, указывается непосредственно при сборке.
Надеюсь, я ответил и на ваш второй вопрос.

[жучара]

Надеюсь, я ответил и на ваш второй вопрос.

нет, я спрашивал, что будет если написать

Architecture: all

На вид- без сучка и задоринки собирается для всех архитектур. Всех-превсех, а их 524. А ради одной or1k пыхтеть надо. И мне непонятно, прав ли я в своих выводах. Я это писал уже, повторяю просто.

[Rootlexx]

нет, я спрашивал, что будет если написать
Architecture: all

all означает, что получившийся двоичный пакет может быть установлен на любую архитектуру. Обычно в таких пакетах содержатся файлы документации, иконки, звуковые файлы и прочие не зависящие от конкретной архитектуры. Пакеты с компилируемыми под конкретную архитектуру файлами не должны иметь "Architecture: all".

[Bizdelnick]

нет, я спрашивал, что будет если написать

Architecture: all

И снова ложь. Был вопрос:

что именно нужно писать сюда и чем руководствоваться

Был и такой:

хрен с ним, со списком, вопрос- где его взять?

Был даже такой:

что конкретно вам непонятно?

И вот такой:

То есть мысль та, что под одну архитектуру (которая не по умолчанию) так просто *.deb файл не скропать. А под все пожалуйста. Так ли это?

Но про то, что будет, если написать Architecture: all — не было.

Так что же Вам всё-таки от нас надо? Вопрос открыт.

[жучара]

Но про то, что будет, если написать Architecture: all — не было.

в процессе тык скыть изучения и возник этот вопрос. Завязывайте троллить уже.

Rootlexx, на словах понятно, но никакой целесообразности в придуманном не вижу. Это ж пришла кому-то в голову идея, сделать так, чтобы для всего (Architecture: all) собиралось просто, а для конкретного чего-то (Architecture: or1k) трудно.

[Rootlexx]

Rootlexx, на словах понятно, но никакой целесообразности в придуманном не вижу. Это ж пришла кому-то в голову идея, сделать так, чтобы для всего (Architecture: all) собиралось просто, а для конкретного чего-то (Architecture: or1k) трудно.

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

Вы сравниваете вещи, которые сами по себе - разного порядка сложности. Создание пакета архитектуры all - это просто упаковка файлов в архив; создание же пакета для конкретной архитектуры - это уже системы сборки, процесс компиляции и связывания, экспортируемые символы и проч., и лишь в конце уже - упаковка в архив.

А как, по-вашему, следовало сделать?

[жучара]

Rootlexx, на словах понятно, но никакой целесообразности в придуманном не вижу. Это ж пришла кому-то в голову идея, сделать так, чтобы для всего (Architecture: all) собиралось просто, а для конкретного чего-то (Architecture: or1k) трудно.

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

Вы сравниваете вещи, которые сами по себе - разного порядка сложности. Создание пакета архитектуры all - это просто упаковка файлов в архив; создание же пакета для конкретной архитектуры - это уже системы сборки, процесс компиляции и связывания, экспортируемые символы и проч., и лишь в конце уже - упаковка в архив.

А как, по-вашему, следовало сделать?

чтобы собрать пакет для архитектуры or1k нужно сделать операции
or1k_0 or1k_1 or1k_2 ... or1k_n-1 or1k_n

чтобы собрать пакет для архитектуры avr32 нужно сделать операции
avr32_0 avr32_1 avr32_2 ... avr32_n-1 avr32_n

чтобы собрать пакет для архитектуры arm нужно сделать операции
arm_0 arm_1 arm_2 ... arm_n-1 arm_n

И так далее.
Так, а чтобы собрать пакет для архитектуры all нужно сделать операции or1k_0 or1k_1 or1k_2 ... or1k_n-1 or1k_n avr32_0 avr32_1 avr32_2 ... avr32_n-1 avr32_n arm_0 arm_1 arm_2 ... arm_n-1 arm_n

Так, а потом мне говорят (вы говорите): знаешь, а на самом-то деле сборка отдельно взятого пакета (or1k) труднее чем для всех пакетов (all)

А самая фишка в том, что она на самом деле труднее. Повторяюсь: для all собирается на ура, а для or1k нет. И я не хочу искать в этом здравый смысл. Как сделали, так и сделали. Не впервой им путать людей. Разом больше- разом меньше.

[Rootlexx]

Так, а чтобы собрать пакет для архитектуры all нужно сделать операции or1k_0 or1k_1 or1k_2 ... or1k_n-1 or1k_n avr32_0 avr32_1 avr32_2 ... avr32_n-1 avr32_n arm_0 arm_1 arm_2 ... arm_n-1 arm_n

/facepalm

Вы бы почитали, что такое архитектура all, раз уж мне объяснить вам не удаётся, дабы не писать такие глупости.

Я просто читаю маны.

Что-то не заметно.

[жучара]

Вы бы почитали, что такое архитектура all, раз уж мне объяснить вам не удаётся, дабы не писать такие глупости.

Чё пишут, то и читаю:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-architecture

Specifying only all indicates that the source package will only build architecture-independent packages

вот чтобы пакет был архитектурно-независим он должен на все архитектуры залезть. А чтобы на все архитектуры залезть, она должен быть собран для всех архитектур. Может это быть проще, чем под одну архитектуру? Ну, они так сделали...

[Rootlexx]

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

Как именно вы предлагаете "собирать для всех архитектур", скажем, текстовые файлы?

Вы просто совершенно не понимаете суть происходящего процесса, оттого и делаете кажущиеся вам правильными, на на самом деле абсолютно не верные выводы.

[жучара]

Как именно вы предлагаете "собирать для всех архитектур", скажем, текстовые файлы?

ну для каждой архитектуры в отдельности можно ведь собрать? А для всех это значит объединить все способы. Я, кстати, уже написал об этом
Re: Какую именно архитектуру нужно писать в поле Architecture при сборке пакетов из исходников?

Вы просто совершенно не понимаете суть происходящего процесса, оттого и делаете кажущиеся вам правильными, на на самом деле абсолютно не верные выводы.

ну так что ж теперь делать? У меня из написанного:

Specifying only all indicates that the source package will only build architecture-independent packages

Больше руководствоваться нечем.

[Bizdelnick]

Сарказм иссяк…

ну так что ж теперь делать?

Перестать спорить и попытаться понять собеседника хотя бы раз в жизни. И не пытаться изучить что-то по документу, написанному для тех, кто уже всё знает, а начать с введения в тему.

https://wiki.debian.org/Packaging/Intro#Step_3:_Add_the_Debian_packaging_files

Architecture

Specifies which computer architectures the binary package is expected to work on: i386 for 32-bit Intel CPUs, amd64 for 64-bit, armel for ARM processors, and so on. Debian works on about a dozen computer architectures in total, so this architecture support is crucial. The "Architecture" field can contain names of particular architectures, but usually it contains one of two special values. any (which we see in the example) means that the package can be built for any architecture. In other words, the code has been written portably, so it does not make too many assumptions about the hardware. However, the binary package will still need to be built for each architecture separately. all means that the same binary package will work on all architectures, without having to be built separately for each. For example, a package consisting only of shell scripts would be "all". Shell scripts work the same everywhere and do not need to be compiled.

[жучара]

Сарказм иссяк…

ну так что ж теперь делать?

Перестать спорить и попытаться понять собеседника хотя бы раз в жизни. И не пытаться изучить что-то по документу, написанному для тех, кто уже всё знает, а начать с введения в тему.

https://wiki.debian.org/Packaging/Intro#Step_3:_Add_the_Debian_packaging_files

Architecture

Specifies which computer architectures the binary package is expected to work on: i386 for 32-bit Intel CPUs, amd64 for 64-bit, armel for ARM processors, and so on. Debian works on about a dozen computer architectures in total, so this architecture support is crucial. The "Architecture" field can contain names of particular architectures, but usually it contains one of two special values. any (which we see in the example) means that the package can be built for any architecture. In other words, the code has been written portably, so it does not make too many assumptions about the hardware. However, the binary package will still need to be built for each architecture separately. all means that the same binary package will work on all architectures, without having to be built separately for each. For example, a package consisting only of shell scripts would be "all". Shell scripts work the same everywhere and do not need to be compiled.

Я вот не пойму, это пишется предполагая, что я не справлюсь с гугл-переводчиком?

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

Вернёмся к нашим баранам. Мой пакет, который "all" собирается легко. Но пакет того же содержания для отдельно взятой архитектуры- трудно. Ваша цитата свет вообще на это не проливает. Не, если вы считаете, что сам идея делать часть больше целого правильна- ну ладно чё. Не впервой.

[Aliech]

жучара, я уже давно стал подозревать, что вы не понимаете, о чём пишете.

all - это архитектурно независимый пакет, не объектные файлы.
any - пакет может быть собран, как содержащий объектные файлы, собирается для той архитектуры, на которой пойдёт сборка (ну или через кросскопиляцию).

[Bizdelnick]

i	Уведомление от модератора Bizdelnick
	Тема закрыта ввиду упорного нежелания ТС понимать данные ему ответы.