On 11/10/2015 11:58 AM, Petter Reinholdtsen wrote: > > I initially went for the 'apt-get install' solution to keep the disk > footprint down by only installing hardware dependent packages on the > hardware that needed it. What is the reason for going with the > dependency approach instead?
The primary motivation is updates on FreedomBox, which we want to start doing soon. - After upgrading freedombox-setup, the user will not run the /setup script again. If done as dependencies, when upgrading freedombox-setup, we can pull in a newer version of a package, or an additional package, if we need to. Doing apt-get in post-inst script would not be possible. - If we look at the current list of hardware-specific packages, that being refactored, it is just flash-kernel (~100 KiB) and firmware-libertas (~7 MiB). The patch doing the dependency approach is a bit incorrect because the dependency of flash-kernel can only be satisfied on ARM architectures. The patch is now superseded by moving the bits into freedom-maker (below is discussion on that). > > [James Valleroy] >> Sunil suggested moving the hardware setup script to freedom-maker >> instead. Then freedombox-setup can focus on configuring a Debian install >> as a FreedomBox, while freedom-maker can handle making bootable images >> for various hardware targets. This will also make it easier to add new >> hardware targets. > > Isn't this going to place files in the installed system that do not > belong to any packages and that will be hard to upgrade using 'apt-get > upgrade'? > The following is the reasoning for doing this: - The hardware setup process that we have is currently to take care of boot stuff. This setup happens only once and future kernel installs are handled by the flash-kernel. They have to be. So, why not make the first time also happen with flash-kernel? We will need to two things from flash-kernel: forcing device when running under chroot and forcing the install location. We might have to fix flash-kernel for this if necessary. After this we will have fixed a bunch of issues that arise from mismatch of our first time assumptions and flash-kernel's later assumptions (this happened with BBB recently I believe). We can remove a lot of hardware specific code. We are open supporting a much larger set of devices easily. - Even now, the files that are created are not really part of any package in strict sense. We are not removing those files when freedombox-setup is removed. We are not upgrading the files when freedombox-setup upgrades. (This change is only for hardware setup script and not for the rest of freedombox-setup that sets up LDAP, apache2, sudoers etc.) In case of Raspberry Pi, the kernel, modules and other boot files are essentially installed by a script. - All the hardware specific parts will only be in freedom-maker. This makes supporting new devices and maintaining existing devices much more easier. - By moving much closer to just using flash-kernel, we are getting closer to Debian way of doing things. We might be able to use d-i one day for building FreedomBox. - Installing hardware specific packages, such as the right kernel flavor, is already being done by the freedom-marker. There is a list of hardware specific packages already over there. We could add flash-kernel and firmware-libertas there. - Most importantly, for all the users who are installing freedombox-setup package on an existing Debian, this hardware specific code either does not run or will spoil their existing boot process. (Debian installer folks seem to have a separate package for such code called flash-kernel-installer. This will setup flash-kernel during image building but should never be installed on a regular Debian machine.) -- Sunil
signature.asc
Description: OpenPGP digital signature
