On Monday 27. May 2019 20.46.32 H. Nikolaus Schaller wrote: > > The pre-built images are just the result of a complete debootstrap in a > fresh chroot on some ARM or MIPS SBC. Either bare bone with some minimal > set of required or generally useful packages or with some more, e.g. a full > GUI like Xfce or QtMoko.
Right. So they are already fully configured. This is the challenge when cross- bootstrapping, and with the CI20 they recommend using qemu for the second stage: https://www.elinux.org/How_to_make_a_debian_rootfs_for_MIPS_CI20 I never got that to work, and given that a lot of the package configuration should be machine-independent (it shouldn't need to see specific hardware), I would rather see some kind of generic configuration getting done, leaving only a small amount of machine-specific stuff, if any, to the actual hardware itself. (Emulation is just a hack because there isn't a nice way of running host programs to do the configuration work within the target environment. So one ends up running emulated binaries that do the same things as host binaries, discarding the portability and interoperability benefits of having a set of programs that behave the same way and can act on filesystems and other things regardless of the system architecture.) So, I decided to use my own tool to make a root filesystem instead: https://hg.boddie.org.uk/qi-emdebian This runs the second stage on the CI20 itself. > Configuration of the LetuxOS is now completely done by some > letux-something.deb packages. So no single file is touched (well, there is > some fallback at the moment that should be eliminated soon) besides through > installing a .deb package. So it can also be removed or replaced (there are > usually preinst and postrm scripts to make backups). The same for the > kernel package. This part starts to sound a bit like Jonas's Boxer tool and its objectives. [remakesd] > Yes, I noticed that you are trying to make it a little more object-oriented > by this approach, especially in the aspect of modularization and > encapsulation of implementations. > > Unfortunately the bash isn't the best OO language :) If I were really going for object orientation, I would probably use Python instead. I did think a bit more about the formulation of systems in makesd yesterday, trying to understand how some of the options work, and it occurred to me that if I were describing the partitioning scheme then I might use a notation like this: ---- partition debian type: ext4 root: debian kboot: latest dboot: latest modules: latest config: latest partition lxde $debian root: lxde partition lc8-boot type: fat size: 5 boot: Letux-Cortex-8/latest kernel: latest devices: latest partition lc8-root $lxde kernel: none devices: none size: 95 system lc8 $lc8-boot $lc8-root ---- The motivation here is that I want to be sure of how many partitions there are, which is not immediately clear from the macro argument syntax. So, partitions are described (using the argument names from makesd in the above as parameters) and can be specialised. Thus, the "debian" partition is a general description of "vanilla" Debian, but the "lxde" definition incorporates the "debian" definition and specialises it. What I would want to enforce is the separation of partitions and other things. Here, I define the "lc8" system as incorporating two partitions. It would not be allowed to just reference "lxde" and then add some overriding parameters: ---- system lc8 $lc8-boot $lxde kernel: none devices: none size: 95 ---- This is because it would become difficult to see how many partitions there might be, and the semantics would need to be considered about what happens when partitioning parameters (like "size") are mentioned: do they declare another partition? This kind of notation reminds me of other things, which I suspect might be these "orchestration" tools people use for cloud computing and provisioning. However, I think multistrap also has some similar notion of specialising definitions: ---- [Debian] packages=udev busybox-static packages=openssh-server openssh-client ... ---- Here, from this extract of my CI20 configuration, the existing "Debian" definition (not shown) is augmented by additional packages. Naturally, multistrap focuses on root filesystem population, not partitioning, but the customisation principle involved seems to be very similar. Paul P.S. In the wider Debian realm, I remembered that there is a Linaro- originating project that tests single-board computers, and I had thought that there might be some tools of interest within that. Here is the documentation: https://lava.collabora.co.uk/static/docs/v2/index.html But it seems like a very heavyweight thing, aimed at continuous integration. And the documentation does not make the parts of interest to us particularly obvious. _______________________________________________ Community mailing list Community@tinkerphones.org http://lists.goldelico.com/mailman/listinfo.cgi/community http://www.tinkerphones.org
