Hi Nigel, > So maybe do an image that then starts off running the ncurses slackware > configuration tool to setup networking / wifi etc etc. may require some > changes / additions for wpa_supplicant. Under all distro's ive tested with > none deal with wpa_supplicant, so it requires manual editing. > > What do you think?
I think the concept is great for systems upon which the installer cannot be used, but what's the real purpose of not using the installer on systems where it can be? To me, the Slackware installer should be able to run on almost anything since it's a light weight curses installer. You can almost (if you're careful) install via the serial console. I provide the installer for systems where the device has an integrated or directly connected 'hard drive'. Therefore the thought is that you're not going to open your device to connect it to an x86 just so you can write a disk image to it. Instead, you boot the installer and install upon the local disk. For systems that run off a compact flash (or similar) only, I can see the point in supplying a disk image, however. If there's a trend of demand towards disk images, a 'first boot' (as they do in Red Hat) could certainly be done (by someone!) where it'd run the /var/log/setup scripts and as you said, run the normal config scripts that are usually run after the installer has finished installing the packages. Whoever maintains support of a community supported device (i.e. not one I maintain in the main tree), they're really free to make the best choices for that environment; but I'd still prefer to have a uniform installation process using the Slackware installer where possible. This way it also hopefully means that there's consistency in stuff that works and that doesn't. When there are images floating around that are made in a non-deterministic way, or with modifications that are unknown about upstream, then it potentially opens the doors to a breakage. Whilst I am thinking about it, if developers are making changes, it'd be useful to let us know on this list (may be making another -devel list in the future if the volume is high). At the moment I occasionally take a look at what people are doing with the Raspberry Pi in order to try and keep the users able to use -current. For example: since the RPi uses an older kernel than provided in the main tree, I need to try and make sure I remember not to recompile glibc with a requirement on a kernel that's not newer than they're using. I don't know the status of Eric's ARM hard float port, but the issues will be the same so it'll be interesting to see how best practices etc develop for this, the current Slackware ARM soft float port. _______________________________________________ ARMedslack mailing list ARMedslack@lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack