Re: ARMv4-support in armel/squeeze?
On Sun, Dec 19, 2010 at 8:30 PM, Wookey <email@example.com> wrote:
> We will be disucssing which arm flavours Debian
> builds/maintains/defaults-to at the Debain Arm/Embedded sprint in
> February. The more info we have before then to make decisions, the
> It's very difficult to support people with reliable old Netwinders at
> one end, and others who want to use all the shiny stuff on their new
> arm netbooks/tablets at the other witout building 6 different arm
> distros. What an appropriate compromise is, is currently a hot topic.
> I guess you just opened it up for more input.
weelll... how about creating an easy means for anybody to create
their _own_ debootstrap'd cross-compiled starting point, based on
_their_ decisions and requirements, and debian can host the most
by "easy" that would mean "one config file" followed by "one command"
(followed by an enormous wait and having large amount of hard drive
space chewed up but that's only to be expected).
* konstantinous has spent weeks if not months on the armhf port
* i remember neil said he spent months - almost a year - on the armel port
* each and every time someone does a new port, all the knowledge and
expertise is re-learned, re-discovered... and then lost.
so why is this the case? why is this information not being recorded
into a reproducible form whereby it is a simple matter of "one config
file" followed by "one command" (followed by an enormous long wait) ?
is it somehow... _deliberate_ that nobody has created such an
automated debootstrap creater? there's been 14 debian ports so far:
_surely_ it occurred to someone that it would be a good idea to
automate the process of creating new ports? is there a debian policy
which _prevents_ people from creating an automated debootstrap
creater? (i'm aware that all ports must be native-compiled but that
simply isn't possible for the "initial" port, so you need some sort of
3-stage-gcc-like-bootstrap "thing" to get to that point).
[ p.s. that last bit about the gcc debootstrap analogy wasn't my idea
in case there's anyone who doesn't want to join in the discussion
"because lkcl must be trying to take control of everything and tell us
how to run the debian project". *sigh*.... ]