Re: Breaking /emul/ia32-linux for squeeze
Hector Oron <hector.oron@gmail.com> writes:
> Hello Goswin et al,
>
> IMHO, the things you are talking about are quite nice. They way it
> works sounds to me a little complex, that it is very close to the idea
> of crosscompiling, as the *right way*, as opposed to accumulate dirty
> hacks and workarrounds that it is what most embedded distros do out
> there. As from my point of view, getting people confused is also not a
> good idea, as what you talk about seems to be much like cross
> compiling, you should face the troubles we face when cross compiling
> the *right way*.
I verry much unifies cross-compiling and biarch. That is true. The
similarity was recognised and planed in.
> As a first step, I would recommend to take a deep though and let
> community and Debian workflow as is (most of the better systems used
> for safety-critical are well proben in time, that helps on having a
> better MTBF -- why break what we have proben for many years?)
It has been though of for years now. At some point there has to be
some acting. The idea, the concept and even a basic implementation has
been around from before sarge and there have been no fundamental
changes in years despide repeated deep thinking about it.
> After some rest and thoughts on paper and ink I would recommend to do
> some cross compiling work, try to bootstrap a minimal set of packages
> for armel (it would be appreciated in emdebian), and you'll find lots
> of tools need to be polished and therefore lots of common and uncommon
> packages. What all this is about is very nice, but needs lots of work,
> if you want to do it the *right way*. Once you realize what one
> architecture implies, then you'll find what an overhead is to think on
> common libcs, oses and arches, plus vendors, it just becomes somehow
> insane.
Which all boils down to DEB_HOST_GNU_TYPE=x86_64-linux-gnu being
unique.
Note that for cross-compiling for multiple architectures on the same
system the GNU tripplet must already be unique or the toolchain,
libraries and headers collide. So this "insanity" is something
inherint in having millions of ABIs for an arch or for uclibc and not
something multiarch creates. That "insanity" also does not affect any
existing Debian arch.
> So, if you like to do wacky ideas[1], I invite you to emdebian land
> and let Debian distro follow their flow.
And I see that they struggle and use dpkg-cross and curse and if you
go back in the thread you see that at least some from the emdebian
camp voiced their wish to replace the dpkg-cross hack with multiarch.
And that it needs a lot of work is not really true. What it needs most
is cooperation. The willingness from maintainers to accept patches and
from Debian in general to accept the multiarch dirs. Packages can be
patched for multiarch as needed and those that need it will do the
work. Need is a great motivater in that respect. So we just have to
light the way and get things started.
> (Please do not interpret me as I am telling what you have to do or
> anything else, i am trying to be as much friendly as I can)
No offense taken.
> Friendly regards,
> Hector Oron
>
> [1] http://wiki.debian.org/EmdebianWackyIdeas
> --
> Héctor Orón
MfG
Goswin
Reply to: