RFC: armbian-build architecture

[TRS-80]

It seems to me like we currently have at least 2-3 separate initiatives going on which are in some way at least touching upon the very heart of the project (the build system).  I wanted to bring attention to them and begin a high level strategic discussion of what the best way forward might be.  I expect this will take some significant time for everyone to really have a chance to weigh in and (ideally) eventually to come to some sort of consensus.

 

I will confess that I don't even really understand the build system myself.  In fact I think only a few people really do.  So as a side effect I hope to increase my own understanding.  And eventually improve documentation.

 

For example I am not even sure any of these initiatives are really conflicting with one another?  But I still feel like we should probably discuss them all together, from a high level point of view.

 

I hope through this process we can come up with some better and more comprehensible architecture which will (ideally) become more accessible to newcomers, ultimately easing the long term maintenance burden (among other benefits).

 

Some of major initiatives I am aware of currently are:

 

rpardini fragment / hooks idea

 

Hooks are used a lot in Emacs for instance, so this idea was immediately comprehensible to me.  It's clear @rpardini has put a lot of thought / effort into that, and there is some very good discussion there, which I encourage everyone to have a good look at.

 

Architecture for adding additional desktop enviromnents, and application groups

 

@Myy has done some nice work here.  I am almost embarrassed to state that I am not even sure if this is what @Rich Neese has been implementing with all the desktop stuff, or not?  Desktop / graphical stuff is not my area and I know @JMCC @jock @balbes150 also have additional multimedia stuff which lie outside Armbian itself, but maybe we have an opportunity to make things a little easier on them here?

 

creating packages in the armbian build system

 

@going has what seem to me like some great ideas, even if I must confess to only partially comprehending them (Debian packaging being a hairy beast I aspire one day to learn more about).

 

I feel like I am probably missing some more, in which case please add links to other discussions you may be thinking about which are related.

 

I encourage everyone to really take the time and try and understand what these people are working on if you have not done so already.  This is probably the most difficult part of this, taking the time and try and really try and understand the other person's point of view (and/or, areas outside our own expertise).

 

In addition to big initiatives above, I recall several offhand comments I read from @Igor and @balbes150 about long logic chains, maintainability, & etc. which I think we need to also discuss in a broad architectural sense.  I don't know the build scripts deeply enough to comment helpfully, but my hope is that the few people who do can have some sort of productive discussion.

 

Besides people I already mentioned, I can see from GitHub that @martinayotte @TonyMac32 @piter75 @Werner @lanefu @Heisath @aprayoga and @gprovost are current members of the project who seem to commit to the build scripts a lot.  Please help me by tagging anyone else you think of who may be interested in this discussion, and apologies to anyone I missed.

[TRS-80]

I guess I felt like that great discussion in rpardini's PR was sort of shut down prematurely.  Maybe the forum is a better place where we can take the long view over time and build more consensus about some of these bigger changes.

 

Here, everyone have a beer and relax, get into right frame of mind.   

[going]

I want to add to the list the topic userpatches organization #2915, which @TonyMac32 started.
This is a fundamental principle and it requires attention.

 

[rpardini]

On 7/14/2021 at 8:54 PM, TRS-80 said:

I guess I felt like that great discussion in rpardini's PR was sort of shut down prematurely.

 

Yes, but fear not, _fragments_ lives on in my branches. I will try to upstream it again eventually, maybe together with more useful features/refactoring based on it.