going

The most interesting thing about this is that the Armbian build system (what is in the lib folder) becomes unnecessary. Only settings and patch folders are needed. If I have OBS, then I need filling in the working directory to build packages. And only this: build> tree packages/deb-build/ packages/deb-build/ ├── htop │ └── debian │ ├── changelog │ ├── control │ ├── copyright │ ├── docs │ ├── install │ ├── rules │ ├── source │ │ └── format │ ├── upstream │ │ └── metadata │ └── watch ...... └── README.md The "watch" file contains all the necessary information to download the source code archive. One line of code is needed and the source package is ready in its expanded form. One more line of code to collect the entire collection of binary and debian source packages. Ricardo thanks for the tip.

The first problem is to make the source package and this must be done in the OS build environment. When there is a properly working source package, and for debian these are several files, we can send them to any service for assembly. It does not matter in principle. No one will do the manual work for us. I am talking about providing the user with tools to work on creating source packages and then assembling them in the native environment, i.e. in the OS in which the binary package will be installed. @rpardini We are talking about the process of developing a package from source texts, and not about which service to build it on. this mechanism can exist completely independently, and can be invoked independently. The build system can use some parts of it for its tasks, but not vice versa. Can we start discussing the algorithm? I'm already doing something and I've done something.

Hi Ricardo. This is my favorite service. Do you suggest making a package in it for Armbian?

Before the mechanism is implemented and moves to the assembly system, it is necessary to ask a question, and who needs it and why. If only to collect a small collection of packages for internal consumption by Armbian as the organization that distributes these packages, then this is one option. This option existed before. If we plan to give the user the opportunity to build any package in a chroot environment or natively, then this is another goal. And it involves assembling several packages for internal consumption. But as part of a more general capability. It was little used because it was hard coded to build multiple packages using configuration files. And it was always the same version of the package. Igor, you know that I have redone it a little, and it is now in the master branch collecting packages in a clean environment every time. Why is this the case? Because all the distributions I know do exactly that. The build system, by its very nature, should provide some customization options and tools for the developer's work. If this is not the case, the developer will find an alternative or redo the algorithm of the build script. There will always be poorly or not very well functioning packages that can be fixed. And for this , there must be a mechanism for building in the chroot environment. I am developing it and it is becoming more functional.

The developers of Armbian abandoned the old mechanism, why? What is the main reason? It worked well and is working today for me. It will be very interesting for me to look at the new algorithm in a descriptive way before it is implemented programmatically.