Discussion: how about Buildroot externals?

[sonicpp]

Hello,

I see you are using modified Buildroot for your purposes and you are merging upstream back to your project from time to time. When I look at this project, I can not see easily what are you changes and what files are kept upstream. So let me put the question: have you considered using Buildroot external for this project? In my opinion, using externals is much simpler to keep project clean and as close as possible upstream Buildroot. You can use all Buildroot architectures, packages and toolchain, but you can put all your custom configs, boards, scripts and packages on top of it. Switching to newer Buildroot is therefore very easy without the need to resolve many merge conflicts (or user of thingos could even use its own version of Buildroot). Or maybe I am just not skilled enough using git to easily navigate in the project.

Since you are (or was?) maintainer of motionieyeos, please let me discuss about this project as well. Since you are merging changes from Buildroot -> thingOS and then from thingOS -> motionEyeOS, things gets even more complicated and maybe using external would make even more sense at least for motionEyeOs. I myself have small project https://gitlab.com/sonicpp/gnss-pi (nothing big as thingos), but using br2-externals helped me a lot to keep the project small and easy to migrate to newer versions of Buildroot. Now I am thinking about to switch from Buildroot to thingos, but keeping using externals. Maybe it would make sense to motioneyeos, too (I imagine motioneyeos is not much different from base project, thingos, only few packages/overlays on top of it)?

Regards,
Jan

[ccrisan]

have you considered using Buildroot external for this project?

I did, but I only found out about it later and never really got the time to plan and try to make necessary changes to simply use an BR's external functionality.

Switching to newer Buildroot is therefore very easy without the need to resolve many merge conflicts.

Agreed, it's always a PITA to do the upstream merge.

Since you are (or was?) maintainer of motionieyeos, please let me discuss about this project as well.

I know it's not a question, but let me answer it :) I was and I'll probably still contribute to it once the rest of the team puts together a new stable version of motionEye.

merging changes from Buildroot -> thingOS and then from thingOS -> motionEyeOS, things gets even more complicated

No doubt about that, but the biggest challenge always was BR -> thingOS.

Now I am thinking about to switch from Buildroot to thingos, but keeping using externals.

Please do that. Changes between BR and thingOS are smaller and smaller with each merge, in an effort to simplify things. Apart from maybe a few changes that I don't know how to deal with using externals, I guess one can easily use a BR external dir on top of thingOS.

This being said, I'm going to try to switch everything to using BR's external mechanism during the next merge with BR upstream.

[sonicpp]

I know it's not a question, but let me answer it :) I was and I'll probably still contribute to it once the rest of the team puts together a new stable version of motionEye.

Buildroot dropped version 2 of Python, so I guess we need to wait until motionEye finish transfer to Python3.

While talking about motionEye... motionEyeOs is main reason why I found thingOS - I own small IP camera (PineCube) and I plan to port motionEyeOs on this board. Because motionEyeOs is based on thingOs, and it is based on Buildroot, I started with Buildroot. I already have working setup with Buildroot and now I am playing with thingOS. Once I am done with that, I can send you a PR to integrate it into upstream thingOS, if you are interested in :)

Now I am thinking about to switch from Buildroot to thingos, but keeping using externals.

Please do that. Changes between BR and thingOS are smaller and smaller with each merge, in an effort to simplify things. Apart from maybe a few changes that I don't know how to deal with using externals, I guess one can easily use a BR external dir on top of thingOS.

Will probably do that, once I get back to the project.

This being said, I'm going to try to switch everything to using BR's external mechanism during the next merge with BR upstream.

Let me know if I can help (I own Raspberry 0, 0w, 2 and 4).

[jbliesener]

Any news here? I'd be willing to help as well...

[avanc]

@ccrisan @sonicpp A short request to get your advice:
I maintain photOS and I'm planing some refactoring. Therefore, my question is, if I should use Buildroot Externals on top of thingOS although thingOS does not make use of the externals feature? Or is it not feasible/possible?

[sonicpp]

@ccrisan @sonicpp A short request to get your advice: I maintain photOS and I'm planing some refactoring. Therefore, my question is, if I should use Buildroot Externals on top of thingOS although thingOS does not make use of the externals feature? Or is it not feasible/possible?

As thingos is "just" fork of Buildroot (with a lot of useful stuff on top) and being rebased on upstream Buildroot from time to time, I think you can use Buildroot externals on top of thingos as simple as you can use them on top of Buildroot - at least I am not aware of any complications. And in my first comment I even mentioned that I am thinking about switching from Buildroot to thingos, but keeping using externals (for my personal project).

I would personally use externals if you plan keeping your "fork" in sync with thingos/buildroot and you dont have any breaking changes in thingos/buildroot, which could not be applied to externals. With externals it is easier to keep your project small, rebasing on buildroot/thingos is not that painful and your repo contains only changes required for your project: thingos/buildroot stuff would be in their own repositories living their own life.

[ccrisan]

The masterplan with thingOS is that it eventually becomes a simple external for Buildroot. It's not a priority but it's definitely the direction towards which we're drifting.

This being said, I think externals are a very good way of dealing with Buildroot-based projects and I believe it's generally a good idea to use them, whenever possible.