On Tue, 03 Nov 2009 20:22:14 +0100
Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Hector Oron <hector.oron@gmail.com> writes:
>
> > Hello,
> >
> > 2009/11/2 Goswin von Brederlow <goswin-v-b@web.de>:
> >> Why do you need --sysroot support? Or what prevents a --sysroot
> >> of / when using the multiarch directories?
> >>
> >> It seems like wasted work with multiarch being a release goal for
> >> squeeze. Hop on the wagon and make it work for you too.
There is merit in having sysroot for toolchain building and multiarch
for toolchain usage. sysroot would then be internal to the toolchain
build.
> > As you already know, multiarch does not have a plan (yet) for -dev
> > packages. In terms of cross compiling, things are unclear which way
> > is painless sysroot or multiarch (orthogonal solutions). The more I
> > think, the more I believe sysroot is painless.
As mentioned off-list, I disagree strongly. sysroot - as it
appears at the moment - retains the hacks in dpkg-cross which means that
cross-building anything more complex than a trivial rootfs becomes
impossible. Cross-building needs to stop requiring package hacks,
package renaming, version string hacks and the consequent complicated
changes to the dependency chain.
dpkg-cross and apt-cross can take us no further - neither package can
have a role in cross-building long-term. The hacks are workable for
only very limited situations. Achieving anything like a reasonable
binary distribution on more than one architecture is all but impossible
- Emdebian Crush 1.0 required many, many individual hand-implemented
super-hacks to get into a releasable state and that was only a few
hundred packages for a single architecture. There is no chance of Crush
2.0 being ready because we simply cannot repeat the same miracle that
gave us Crush 1.0 without ditching the hacks in dpkg-cross. Once we
have multiarch, Crush 3.0 for Squeeze+1 will be the objective,
supporting several hundred (maybe a few thousand) packages all on at
least four architectures.
http://lists.debian.org/debian-embedded/2009/08/msg00005.html
*Any* method that requires any kind of hacks like the current ones in
dpkg-cross will not be capable of supporting a sane cross-building
system for a cross-built binary distribution.
If sysroot can work without hacks, maybe it could be usable but the
removal of the hacks is the imperative here.
> Your cross-libfoo-dev package would have to solve this.
Changing package names is not acceptable - that is what is causing the
current logjam. The cross package needs to retain correlation with the
file in the archive so that the foreign package can be upgraded
alongside the native arch package and so that the foreign package can
be installed whilst taking into account the existing Arch:all
dependencies.
In essence, 'apt-get upgrade' would need to be able to upgrade the
native arch and the foreign arch at the same time - or at least tell
the user that the native upgrade also needs a few foreign packages
upgraded. Otherwise, what happens (now) is that as the foreign package
(with a changed package name) cannot be correlated with the package from
which it was built, the built package is therefore removed (with all
it's foreign reverse dependencies) if there is any kind of transition.
The removed foreign packages then need to be reinstalled all over again,
once the native packages have upgraded. Even if the resulting process
actually does this, it's better to do this in one operation. Merely
allowing the frontend to realise that the foreign package has been
updated in the archive, makes it possible.
The problems are outlined in #502433. The dependency calculations need
to take account of what is already installed as foreign without native
versions being considered, yet still take account of Arch:all - AFAICT
multiarch allows this mode. For it to work, the package actually
installed has to retain a correlation to what is in the Packages file,
so that the correct dependency chain can be constructed. Changing
package names (or even version strings due to strict versioned
dependencies) in such situations is only going to lead to
non-installable combinations, as we have now.
The current behaviour of dpkg-cross interrupting the process of
downloading, rebuilding,renaming and then installing packages *has*
to stop. The current dpkg-cross hacks have to be removed and dpkg needs
to be able to understand how to deal with foreign versions of -dev
packages in a multiarch setting - then frontends like apt need to be
able to calculate the dependencies correctly. (This *should* be as
simple as identifying which packages are foreign then starting the
dependency calculation from the Packages file for that arch, taking
account of Arch:all packages that are already installed {as most
frontends already do}).
> Usualy the
> cross-libfoo-dev package would only contain the *.so link in
> /usr/lib/arch-os-libc/ and depend on the normal -dev package.
Forget dpkg-cross, it is a dead package walking. The hacks upon which
it utterly relies need to be dropped.
> For multiarch the problematic part is actually just splitting out the
> *.so links into an arch:any package and common header files into an
> arch:all package. A lot of work to modify rules files and lots of new
> tiny debs for the archive (and NEW processing). So it got put off for
> later. Your dpkg-cross can automatically do this in 99% of cases
> leaving verry little handholding.
Please drop ideas of dpkg-cross working with multiarch - what remains
of dpkg-cross after multiarch will not be anything like what it
currently achieves. We need a system that can work without mangling
package names (as this corrupts dependency calculations) and without
interrupting the normal package installation process. That way,
'apt-get -a armel build-dep foo' becomes practical - that's what
cross-building needs from multiarch.
In particular, we *really must* stop renaming packages when installing
a foreign version of a -dev package. I might be wrong, but I thought
that was what multiarch promised - at least if considering a -dev as if
it was just another package.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgpkOFga48p89.pgp
Description: PGP signature