Re: armelfp: new architecture name for an armel variant
Dear developers,
2010/7/13, Riku Voipio <riku.voipio@iki.fi>:
> Subarchs could also be useful if we wanted to build softfp abi compatible
> armv6/armv7 armel builds of the whole debian repository. Of course we could
> do
> builds without subarchs, but then users would be unable distinguish which
> installed packages are for which cpu, and providing that via debian infra
> would not be possible.
Having ABI support in dpkg (already discussed on 'armel' port) could
had been helpful, indeed, as all the upcoming differences between
processors, could make much sense. But is it worth the extra burden of
having to implement such support, arriving to consensus and do the
needed changes in the archive as well as deal with dependency solvers?
Back the, when, at Extremadura [1], when 'armel' was picked up as
new architecture, was said that "in Debian a new ABI is a new
architecture". Could we have been wrong and should we had instead
tried to add ABI field to then control file?
Would you, dpkg maintainers, think that it is worth to go through the
extra hassle of adding such field without having an implementation,
having to change the archive, dependency solvers and achive a
consensus among the rest of the community? Might be the right way for
long term support (which does not mean it has to happen now).
[1] http://wiki.debian.org/DebianEmbeddedWorkSessionExtremadura2006
Best Regards,
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
Reply to: