[ARMedslack] Hello everyone

[Stuart Winter]

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.