Refactor directory structure?

[multi-io]

Can we get rid of this notion of "the parent directory of the project directory", below which the project as well as the sources and output directories must be located? It's a fairly minor nuisance, but this rigid directory structure with the compile starter script outside the project imposes complications in automated Vagrantfile/Dockerfile setups -- you have to copy the compile script separately and sync-mount the lib directory a second time because the default location (/vagrant) doesn't fit the build scripts' expectations. We could modify the scripts to refer to the project directory via some generic opaque variable like $PREFIX rather than $SRC/lib, and allow you to have the cache and output directories anywhere in the filesystem.

[zador-blood-stained]

I think it can be refactored this way:

• compile.sh is left in the repository root directory and doesn't have to be moved, especially since parameters can be set via command line or config files
• all build scripts are moved into a "lib" subdirectory
• output, sources and toolchains directories are created in the repository root and also added to .gitignore. They should be movable by editing some variables, but it may not be needed with this kind of setup.

This is a large refactoring work and it will require cleaning up old directory structure manually by the user, but it can be done to improve compatibility with containers and VMs.

[igorpecovnik]

@zador-blood-stained proposal sounds fine to me. We have to do this once and perhaps now is right time ... we are just after release. Let's set new structure at new branch and when we are satisfied, move and adjust scripts?

[igorpecovnik]

Perhaps Oleg @150balbes might also come up with some ideas regarding rfc?

[150balbes]

IMHO it is desirable to split the build scripts and the data used in these scripts. For example, the list of packages (PACKAGE_LIST= , PACKAGE_LIST_ADDITIONAL=, etc.) to build (file configuration.sh) to put in separate directories\files.

[zador-blood-stained]

First/PoC version pushed to a new branch. Not tested yet (and doesn't require testing yet too) because it will need a lot of cleanups and changes, and then adaptations to Dockerfile and Vagrantfile.

IMHO it is desirable to split the build scripts and the data used in these scripts. For example, the list of packages (PACKAGE_LIST= , PACKAGE_LIST_ADDITIONAL=, etc.) to build (file configuration.sh) to put in separate directories\files.

This can be implemented in the future, but it's relatively easy compared to changing the build system root directory.

[igorpecovnik]

This can be implemented in the future, but it's relatively easy compared to changing the build system root directory.

We can do more rfc in this area :) since it would be nice to shrink default image, remove non urgent packages (including compiler, kernel headers, ...) and put them into new virtual package, which can be installed later from armbian-config or manually.

But first, essentials, yes.

[zador-blood-stained]

Headers and other kernel packages will need a planned (long ago) rework too to support DKMS, I'll probably add a page with some details in the "Projects" section.

Regarding cleaning up the image, I was thinking about removing testing and benchmarking tools from stable images, but we'll need @ThomasKaiser 's opinion on this and ensure compatibility with armbianmonitor and other tools.

[150balbes]

As an option. Creates a SRC directory, there are subdirectories-groups (e.g. by types of processors or platforms), these subdirectories contain the following subdirectories (specific models), which already hosts the description, the template files and other files required to build the specific project. Build scripts are in the "binary" directory in the root build system. When the Assembly is run, the script scans the SRC directory and builds a tree of available projects. Name directory\subdirectory is the project name. After selecting the desired project or group, is assembled using the templates from this project.

---

Duplicates the text in their native language, because the translation can lose meaning. Как вариант. Создается каталог SRC, в нём размещаются подкаталоги-группы (например по видам процессоров или платформ), в этих подкаталогах находятся следующие подкаталоги (уже по конкретным моделям), в которых уже размещается описание, файлы-шаблоны и прочие файлы необходимые для сборки конкретного проекта. Сборочные скрипты находятся в своём "бинарном" каталоге в корне сборочной системы. При запуске сборки, скрипт просматривает каталог SRC и на его основе строит дерево доступных проектов. Имя каталогов\подкаталогов является именем проекта. После выбора нужного проекта или группы, выполняется сборка с использованием шаблонов из этого проекта.

[zador-blood-stained]

Не совсем понимаю цель таких изменений. По сравнению с тем, что было пару лет назад, значительная часть конфигурации отдельных плат и платформ уже разбросана по отдельным файлам. Или имеется в виду различный набор Debian/Ubuntu пакетов для различных плат/платформ?

[ThomasKaiser]

Regarding cleaning up the image, I was thinking about removing testing and benchmarking tools from stable images, but we'll need @ThomasKaiser 's opinion on this and ensure compatibility with armbianmonitor and other tools.

I don't think that's a great idea for a simple reason: since people find instructions on the forum and somewhere else that won't work any more afterwards. If packages are removed there must be a single and simple option to re-add them in a single step later (armbian-config?)

[zador-blood-stained]

I don't think that's a great idea for a simple reason: since people find instructions on the forum and somewhere else that won't work any more afterwards.

Usually command-not-found will suggest installing packages when commands are entered interactively, but I remember that it didn't work on Armbian images for some reason.

If packages are removed there must be a single and simple option to re-add them in a single step later (armbian-config?)

Yes, that's why I didn't suggest that earlier and had just a TODO entry for myself like "Script/option to install or remove testing and benchmarking packages"

[ThomasKaiser]

Well, it works like this: 'Please do an apt install iozone3'... 'This does not work, Armbian is broken'.

 tk@lime2:~# apt install iozone
 Reading package lists... Done
 Building dependency tree       
 Reading state information... Done
 E: Unable to locate package iozone 

I deal with stuff like that in my business life where it's somewhat ok when being paid per hour. What's the amount of disk space saved when removing these packages?

[zador-blood-stained]

What's the amount of disk space saved when removing these packages?

Too little to be worth the support effort if there are existing tutorials and examples for these tools.

[ThomasKaiser]

Judging by

dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -n

removing the developer stuff from images (maybe including linux-headers package) might be the better idea. And then a simple armbian-config option to install all of this in a batch. Not shipping with linux-headers by default might also decrease overall apt upgrade time needed on all Armbian installations world-wide extremely (also breaking compatibility with existing instructions but this time people who want to compile drivers are affected and those might be able to read -- partially an update needed -- Armbian documentation)

[zador-blood-stained]

Well, it works like this: 'Please do an apt install iozone3'... 'This does not work, Armbian is broken'.

After thinking a little bit about this, should we really take this into account? People downloading Debian/Ubuntu and not willing to understand how to work with APT may as well download a different distribution that is focused on providing dialog-based interface for installing packages.

[150balbes]

If you make all the settings (including all scripts\templates ) which are used to specify the specifics on models\groups\packages in separate directories, then simplifies themselves "executable" scripts (which build) + all logic become easy to understand. Now in the scripts of many places where the choice of\branching depending on what type\model of the collected image. For example, I to build an image under s905 does not need any data from Allwinner, but they partially get in my images or have to edit the scripts-that-be to change that. In my build environment to become not compatible with the common branch. Maybe I'm not explaining it very well. I offer everything to do with the specific build of a specific image (under konkretnuyu model of equipment) to be moved to separate subdirectories and to divide the build process into modules\steps (stage1 is a set of packages for the image, stage2 - create u-boot stage3 - create the kernel, etc.) from which as from the designer to collect the needed sequence of Assembly of the final product. Now, for example, there is a extra directory in which are located the build scripts of certain packages, these packages come in all assemblies. If there are separate directories for models, then these scripts\templates\data (from the General catalogue of modules and templates) can be used as references in your subdirectories (on specific models). If you want to make your changes to this script\template (something to do), it simply copy to the directory from the model and rules\change. If the template is not needed, then it is not referenced in the catalog of models and it is not processed and does not enter the Assembly process. If you need specific scripts or actions to build your own image, you need only in this way, add this script to your directory of the model (e.g. with a certain extension in the group\subdirectory of the desired step (stage1, stage2, etc.). If you separate the build process (executable scripts) from data, we can easily extend the range of collected products, just copy the generic (test template is a subdirectory), make your edits (changing the contents of the subdirectory, add its description build the kernel, you need a turnip with packages, etc.). There will be no limit on the number of possible variations of the kernel options set of packages, output the result (a tar archive, the image, the image is ready for flashing, etc.). This is easy to be included into a branch without destroying it.

I do not impose it, just a suggestion.

---

Если вынести все настройки (в том числе все скрипты\шаблоны ) которые используются для указания конкретики по моделям\группам\пакетам в отдельные каталоги, тогда упрощаются сами "исполняемые" скрипты (которые выполняют сборку) + вся логика становиться легко понимаемой. Сейчас в самих скриптах много мест, где происходит выбор\ветвление в зависимости от типа\модели собираемого образа. Например, мне для сборки образа под s905 не нужны ни какие данные от Allwinner, но они частично попадают в мои образы или приходиться редактировать скрипты, что-бы это изменить. В результате моя сборочная среда становиться не соместима с общей веткой. Возможно я плохо объясняю. Я предлагаю всё, что связано со спецификой сборки конкретного образа (под конкреную модель оборудования), перенести в отдельные подкаталоги и разделить процесс сборки на модули\шаги (stage1 - это подготовка набора пакетов для образа, stage2 - создание u-boot, stage3 - создание ядра и т.д.) из которых можно как из конструктора собирать нужную последовательность сборки конечного продукта. Сейчас, например, есть каталог extra в котором находяться скрипты сборки конкретных пакетов, эти пакеты попадают во все сборки. Если будут отдельные каталоги по моделям, тогда эти скрипты\шаблоны\данные (из общего каталога модулей и шаблонов) можно использовать как ссылки в своих подкаталогах (по конкретным моделям). Если нужно внести свои правки в такой общий скрипт\шаблон (что-то убрать или добавить), его просто копируешь в каталог от модели и правишь\изменяешь. Если шаблон не нужен, то на него нет ссылки в каталоге модели и он не обрабатывается и не попадает в процесс сборки. Если нужны свои специфичные скрипты или действия для сборки своего образа, нужные только в этом образе, добавляешь такой скрипт в свой каталог модели (например с определённым расширением в группе\подкаталоге нужного шага (stage1, stage2 и т.д.). Если отделить процесс сборки (исполняемые скрипты) от данных, можно легко расширять линейку собираемых продуктов, просто копируешь общий (тестовый шаблон-подкаталог), вносишь в него свои правки (меняешь содержимое подкаталога, добавляешь своё описание сборки ядра, нужные репы с пакетами, скрипты, патчи и прочее). Тогда не будет ограничения на количество возможных вариация ядра, вариантов набора пакетов, выходного результата (tar архив, образ, готовый имидж для прошивки и т.д.). Такой новый продукт легко включить в общую ветку, без ее разрушения.

Я не навязываю, это только предложение.

[zador-blood-stained]

Current version of the upgrade notice dialog

Если вынести все настройки (в том числе все скрипты\шаблоны ) которые используются для указания конкретики по моделям\группам\пакетам в отдельные каталоги, тогда упрощаются сами "исполняемые" скрипты (которые выполняют сборку) + вся логика становиться легко понимаемой.

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

Например, мне для сборки образа под s905 не нужны ни какие данные от Allwinner, но они частично попадают в мои образы или приходиться редактировать скрипты, что-бы это изменить. В результате моя сборочная среда становиться не соместима с общей веткой.

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

Сейчас, например, есть каталог extra в котором находяться скрипты сборки конкретных пакетов, эти пакеты попадают во все сборки.

Для каждого скрипта в extras есть условия (пусть и не идеальные), а если добавить

EXTERNAL=no
EXTERNAL_NEW=no

например, в config/sources/vegas95.conf, то ничего дополнительного в результирующий образ для этой платформы добавлено не будет.