Re: armelfp: new architecture name for an armel variant
On 7/9/10, Matt Sealey <neko@genesi-usa.com> wrote:
> How much extra work is it for example to append something to the package version? For instance take a backport or ubuntu package of foobar-1.0 which may end up as foobar-1.0ubuntu5 or foobar-1.0~dsfg9 or so?
Changing the floating point method and the ABI is a change at right
angles to package version numbers: anu version number could be built
with either FP method.
I did something like this to make a small armel (softfp)
MaverickCrunch repository, by adding +crunch to the version numbers so
that they would supercede the official ones. It turned out to be a bad
solution, because the main repository then got +lenny1 versions for
backported security fixes, which only superceded the +crunch ones by
pure luck because 'l' is after 'c' in the alphabet.
In that case the packages were compatible with standard armel and
meant to be used with it.
In this case, a whole new universe of Debian packages, incompatible
with the standard ones, needs to be made, and the usual way to do that
is to make a new Debian architecture, however painful and error-prone
that may be.
> Hardfloat packages can be built from identical sources in nearly all instances
I'm really not up to speed on what the extra gilded etc mean if
anything so I am not sure it is a valid solution, but it's a thought.
~ is special in that it sorts *before* every other character, so
1.0~anything is a preliminary release that should be superceded by 1.0
and 1.0*. +something is used to give a "later" debian version of the
same thing.
> Martins qualm is especially relevant re the detecting arch/flavor based on a compiler tuple which could be identical for both.
It would certainly cause less trouble if we avoid having to modify the
build scripts of 19000 packages; they come in all flavours and were
all hacked already where necessary to recognise arm*-{*-}linux-gnueabi
during the armel port.
> What it needs is for the packaging tools to know the difference
The usual ways to do this are either to use a different architecture
name in the same repositories, or a separate repositories.
FWIW, the technique which was the most successful in building
Maverick-accelerated Debian packages for armel was not to mangle the
compiler, but to wrap the standard compiler with a script and use PATH
to catch the many different names that build scripts use to call the
compiler, prefixing the desired compiler options to the gcc command
line:
mkdir /usr/local/vfp
cat > /usr/local/vfp/gcc << EOF
#! bin/sh
exec /usr/bin/gcc -march=armv7 -mfpu=vfp -mfloat-abi=hard "$@"
EOF
chmod 755 /usr/local/vfp/gcc
ln -s gcc /usr/local/vfp/cc
ln -s gcc /usr/local/vfp/gcc-4.3
ln -s gcc /usr/local/vfp/arm-linux-gnueabi-gcc
export PATH=/usr/local/vfp:$PATH
That gets almost all the packages to build in one shot because It's
very rare for a package's build script to override -march, unheard-of
for it to touch the other two.
That was building against the standard libraries, so ld, libtool and
friends needed no extra magic in that case.
As to whether it's worth hassling all the DDs to add yet another port
name into lots of packages' control files along with arm, armel, armeb
and go through the QA stuff again to identify all packages with Arch:
lines, with debian/rules files that switch on arch names and so on...
My feeling is that that could be a pretty unpopular request only two
years after askng everyone to do that for armel.
Someone will also need to do the QA again to check for binary packages
that are arch-specific. I may still have the script lying around
somewhere to do that...
The only thing I can think of that would _require_ inventing a new
Debian architecture is if this port is ever going to be accepted into
Debian proper and use the system of Debian mirrors. Is there some
other reason?
M
Reply to: