Anthony Towns wrote:
Please do Cc: me if you need any additional info. There's no need to
Cc: me if you're all able to make these decisions on your own, although
you're welcome to if you like.
On Mon, Feb 23, 2004 at 05:49:57PM +0000, Wookey wrote:
You're right of course, and as you observe it really is getting to 'make it
work or have arse kicked' time. Part of the problem is of course that arm
installation has always been somewhat 'distributed' - there is a special
version of bootfloppies for most 'supported' machines because the default
one doesn't actaully work, and an awful lot of people using debian-derived
stuff don't use either b-f or d-i to get things installed - they use some
random bootloader for the board in question.
That's fine; if you guys (the arm porters) think that's the best way of
installing arm, then that's what we should support. Work out how to do
it, make sure the stuff people need is in the archive, and document it,
and that's fine. It's better to have what people actually use on arm
be the recommended installer for arm, than what people use on other
platforms. If that's also easier and quicker to get working (because
it's already working, say), that's even better.
So in fact debian-arm remains useful to a lot of people even without a
working debian-installer.
So, your first step is to make sure you that sarge/arm is useful to
those people, even without _woody_. If it's not, you need to make it
so: woody's not going to stay around forever. If it is, then you should
think about whether you just want to document and support whatever it
is you've already got, or if we would be better off have d-i on arm like
everywhere else.
A possible scenario is changing debootstrap so that it doesn't need any
compiled components, so can be run on anything with a POSIX sh (and a few
other things) to unpack an root filesystem that can be exported over NFS
(eg). If that's enough for what people are using Debian/arm for, that's
fine: we need to make debootstrap work for those people in the majority
of situations (and in particular for new users who aren't already using
Debian), and put it in the archive along with some instructions.
The time to make these decisions and start working on them is now.
If people have the time to work on both some specialised installation
method and d-i for arm, but still have at least one or the other finished
and working in the very near future, that's fine, of course.
I'd encourage you to focus on what's best for arm users and on what's
likely to actually be able to be mostly completed within the next month
or so. If there are other alternatives that are feasible and effective
within those constraints, that's fine too.
The final option that's available is to declare some architectures to be
"upgrade only", and work on promoting them to "new installs and upgrades"
in point releases after sarge's r0. I'm strongly opposed to this (although
it's not been ruled out), and I don't think it'll be effective. The
possibility does exist as a very last resort though.
(Some of the above stuff might require changes to debootstrap. Do talk
to me about them before assuming they're impossible; some of them are
already being done, but are fairly low priority. They can be bumped up
if arm needs them to release.)
Cheers,
aj
*Maybe* What is needed is one or two well documented examples(i.e. a
cookbook) on how to use (the new) debootstrap
and how to extend it do differennt arm architectures/boards/projects
that an embedded company or individual may
purchase or build. That way, lots of folks, could follow the
patern(cookbook) to extend debootstrap
to the various arm projects. Many folks, who are extremely interested in
debian+arm for embedded
projects do not work exclusively on debian or arm projects. So their
skills are not quite as 'fresh'
or current as those persons lucky enough to work primarily on debian and
arm projects. I believe a cookbook
approach to extending debootstrap to a new arm project, so that the
common minimal things work,
ethernet, serial, CompactFlash/Smartmedia, jtag, etc...would be a good
idea. A cookbook example would
go a long way to attracting talented embedded programmers from a
traditional development platform
and kernel to debian+arm. Persons who code in various assemblers and
ansi C, usually pic up linux
quite quickly. There are many windows+ state_machine programmers looking
for a clear, documented
path to embedded linux.
I would caution, from my limited arm experiences, that supporting the 2.6.x
kernel is paramount to attracting new arm projects, to use Debian+arm. I
understand that the kernel
is separated from the distro, but, new embedded projects tend to
want/need new technology. When
I consult to small and medium size companies about using embedded linux,
the features
of the 2.6.x kernel always come up as the central issue in there
decision. So I guess what I'm
saying is during the bootstrap/installation, the target kernel is the
most important thing for
embedded programmers. The kernel version and or kernel options should be
clearly delineated
in at the start of the installation, regardless if it is DI or
debootstrap.....
It would be a fantastic world if their(embedded developers') first
decision was what kernel (embededded Linux) to use,
then their second decision is what development platform (debian) to use,
and their thrid decision is
which microcontroller (arm) to use. Safely knowing that tool vendors and
technology companies cannot
force one to use a particular platform while developing embedded linux
based technology, is a rare
comfort.
James
