Hi Tomek, Thank you for your feedback.
Yes, I suggested Aviral submit the PRs early to get more feedback and ideas from the community. I think the idea of the NuttX Distribution is not restricted to Linux Distro, but to make it easy for anyone to create their own distribution system. This way they could select which packages will be available on their server. We are not thinking of having a central server with compiled packages (like OpenWRT for example), not because it is not possible, but because it will require more team efforts (that we don't have at the moment). The idea is to have something between opkg, so the cache will be saved at /var, but we don't have plan to use sqlite (it is too big to use a small MCU), the idea is to use common text file (maybe JSON) it will require less resource. BR, Alan On Mon, May 11, 2026 at 11:00 AM Tomek CEDRO <[email protected]> wrote: > Hello world :-) > > As we have fist PR [1] with package manager for NuttX by @aviralgarg05 > and this is step towards NuttX RT-OS "distribution" lets talk about > its architecture :-) > > First of all I would like to propose starting from creating > architecture document and then proceed with implementation so we have > clear vision on the road ahead :-) This documentation should be easy > to edit, thus we may use ASF Confluence WIKI? > > As as BSD user I will for sure give FreeBSD as an example because this > is what I found really elegant and future-proof :-) > > Term "distribution" comes from the Linux world and is not well > perceived in the BSD world where FreeBSD or OpenBSD or NetBSD are not > "distributions" but fully featured standalone and complete operating > systems. I would love NuttX to be that way too - that we have NuttX as > one common coherent environment and not many "distributions" competing > with each other. Thus my proposition to stick to the BSD approach and > thus naming like NuttX RT-OS that would resemble RTOS but also > complete coherent and standalonde OS solution. > > Below are my remarks I already put on the PR. > > Regarding RT-OS organization: > * BSD systems are divided into BASE and USERLAND. This may come handy > for NuttX too because BASE could be the static firmware images built > for specific platform, and then USEDLAND would provide packages for > that platform. This clear separation assures clean and elegant > implementations. > * BASE is located in `/`. > * USERLAND is mounted at `/usr/local` when BASE is ready. > * BASE can work without USERLAND. > * BASE is common to all releases and platforms providing minimal > common feature set. > * This allows to have static BASE at `/` with USERLAND mounted from > anywhere (i.e. network or separate partition) at `/usr/local`. > * Breaking USERLAND never breaks BASE, so you can easily fix stuff > when in pinch. > * This BSD is different approach from Linux where is base and > packages are intermixed, and I would love this approach in NuttX RT-OS > :-) > > Regarding NXPKG: > * I would suggest FreeBSD following `pkg` [2] organization which is > similar in name and functionality (also smaller and simpler than > `apt`, `pacman`, etc). We may use `nxpkg` in place of `pkg` below: > * Configuration is plaintext at `/etc/pkg/` and then `nuttx.conf`. > * Package database is in `/var/db/pkg/local.sqlite`. > * Package cache is in `/var/cache/pkg`. > * Each package knows its dependency packages, and pkg is able to solve > them. > * There are also "package flavors" that is each package can have > different feature set enabled/disabled, but this is story for future > here, we just need to keep it in mind when designing architecture. > Lets start with small measurable steps. > > This way we would stick to the current approach where BASE is just > custom firmware, while enabling NXPKG would enable USERLAND (or vice > versa). > > If we want NuttX RT-OS then we should consider minimal and common set > of functionalities for BASE. > > Let me know what you think :-) > Tomek > > [1] https://github.com/apache/nuttx-apps/pull/3474 > [2] https://man.freebsd.org/cgi/man.cgi?query=pkg > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
