On Tue, 03 Nov 2009 20:22:14 +0100 Goswin von Brederlow <goswin-...@web.de> wrote:
> Hector Oron <hector.o...@gmail.com> writes: > > > Hello, > > > > 2009/11/2 Goswin von Brederlow <goswin-...@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/
pgpwBoiZuD3SP.pgp
Description: PGP signature
