Dear developers, 2010/7/13, Riku Voipio <riku.voi...@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." -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikereidzmsvjqdjrqxzrfc2rc4gpxoyfinvs...@mail.gmail.com
