Re: Emulated buildds (for SCC architectures)?
On Tue, Mar 22, 2005 at 08:58:41PM -0800, Steve Langasek wrote:
> > Now, if we face dropping one or more of our architectures (i.e. m68k)
> > because new hardware can not be found anymore (the Vancouver proposal
> > mentions that "the release architecture must be publicly available to
> > buy new" in order to keep it as a fully supported architecture - I
*cough*
You can still buy new Amigas. See http://www.vesalia.de/ for example.
Of course, one can start new discussing what's actually is new? Those Amigas
are new and unused and include warranty.
> > know, SCC != fully supported, but anyway, a buildd can die and create
> > huge problems to a port), why shouldn't we start accepting buildds
> > running under emulated machines?
> I quite agree with Anthony that if we have to emulate the machine, there's
> not much sense in supporting it.
Especially when certain things are essential for those archs, like gcc for
embedded systems.
> I do know, from first-hand experience trying to get ssh running on a Cobalt,
> that compilation speed is not always correlated with the usefulness of a
> system; so I'm not completely opposed to using distcc (in moderation!) for
> release architectures, but I would still first like to see some serious
> discussion about why it's useful to build all the software we do for all the
> architectures before agreeing that such a distcc network is warranted.
I doubt that m68k would gain much profit from using distcc. The preposessing
still needs to be done on the m68k. Usually, m68ks only have 10 Mbps
ethernet, which is often limited to 300-600 kB/s in real life usage. I don't
have a proof, but I think for some NICs there's no DMA supported or so. So,
with using distcc (over network) you might buy that remote compiling by
raising the CPU load.
Basically I agree, that not all packages need to be compiled natively on
m68k and that some packages don't need to be considered as RC, such as KDE
or other long building ones. For those packages a distcc approach might be
useful.
I would prefer a reduced release set of packages over even considering the
drop of archs. Release a set of packages for basic and server tasks and let
all desktop related stuff (X, KDE, Gnome) do their own subreleases on the
base of the main (reduced set) release.
That way, servers still could run stable for a long time (2 years release
cycle f.e.) whereas Desktop users could use newer software for KDE/Gnome
with maybe a 6 month release cycle for those subreleases.
--
Ciao... //
Ingo \X/
Reply to: