On Tue, 19 Jan 2010 20:57:19 +0100 Goswin von Brederlow <goswin-v-b@web.de> wrote: > I've been working on a next generation apt/dpkg-cross that will > support apt, aptitude, synaptic (anything libapt based) and dpkg > directly. Why? There is no future for apt-cross or dpkg-cross - there should be no next generation. We get through the multiarch transition and both dpkg-cross and apt-cross disappear for GOOD. Has this been done alongside the existing changes already described for the multiarch transition? Can you make the patches available somewhere? > Interface: > ========== > > - dpkg-cross just like you are used to. Only until enough packages have been made multiarch-compliant. In the meantime, dpkg-cross merely needs to make the empty, dummy, packages already described. > - Wrappers in /usr/lib/apt-cross/. Add that dir to your PATH or link > them from /usr/local/bin and you can install foreign packages > transparently with just dpkg. This has some sideeffects so maybe don't > use this. I can't see that as a good idea but I also don't see why it is considered necessary. /usr/lib/apt-cross/ is the wrong name. It has to be a name based on an arch triplet, but we're already using those. > - apt-get, aptitude, synaptic (anything libapt based) are > automatically setup to support -cross packages (just needs > configuration to know which archs). This is the main area of work, but not for -cross packages, for true multiarch packages. > Using those you can manage your system just like you are use to. The > following will all work fine including for -cross packages: > > apt-get update > apt-get upgrade > apt-get dist-upgrade > apt-get install foo libbar-arm-cross > dpkg[-cross] -i libbaz_1.2-3.arm.deb dpkg has to do that, not dpkg-cross. Why are we still looking at -cross packages? > apt-get build-dep bash-arm-cross > > This will install all the build-depends of bash but install the > libraries as arm-cross instead/on top of the native libs so you can > cross compile bash. This is still experimental but it looks like it > works well so far. If multiarch works properly, this isn't necessary. What we'd need is just: $ sudo apt-get -o Apt::Architecture=armel build-dep foo (if someone can make that into '-a armel' it would be a lot easier.) > This would install a 32bit bzip2 on amd64 including any needed > libraries. It requires a non-default configuration saying that it is > OK to have foreign binaries though and is only usefull for e.g. i386 > binaries on amd64 where they can be executed. But you could use the > same with qemu to run them. Usefull to test a bug that only happens on > one architecture. But, let me repeat it, this will require extra > configuration to prevent accidentally replacing native binaries with > foreign ones. Why? If apt or aptitude understands multiarch properly, the dependency resolution will be able to work out which are same and foreign etc. and proceed as appropriate. > Last there is also a tool (convert-cross) to convert deb packages > instead of installing them. The same mechanisms used during install > (see implementation below) are used to convert libfoo_1.2-3_arm.deb > into libfoo-arm-cross_1.2-3_all.deb (or a dummy > libfoo-arm-cross_1.2-3_arm.deb if multiarch). Those packages can then > be put into a repository and installed with plain apt and dpkg. Those > that don't like on-the-fly conversion can use that to get identical > results. Please can we get rid of all -cross ideas? The whole point of multiarch is that all -cross stuff goes away. Simon did have a -cross repo - I'm not sure if that is still operational or whether the problems were fixed. > That is usualy it. That automatically enables all apt sources for the > archs listed. But you can do more in /etc/apt/sources.list[.d]: apt needs to be taught how to keep multiple lists safely - changing arch causes apt to delete all lists for the other arch, changing back removes them again. Some of the problems with apt-cross are because apt-cross tries to stop apt doing this and then the apt bindings get confused. > /etc/apt-cross/black.list: > > Filter blacklisting packages from conversion. By default this prevents > any binary available natively to be converted. ? There is support in the MultiArch Spec for such limitations, why a separate one? > It further explicitly > excludes dpkg, apt, aptitude, type-handling and a few more from ever > being converted. That won't work. apt provides a SONAME that needs to be available as armel when cross-building things like aptitude. apt does need to be installed as a multiarch package. > They would really mess up the system if you > tried. Umm, it works OK if the installation locations are done properly. The current apt-armel-cross package IS a necessary one. > This is used only by "apt-get update". Please drop any mention of apt-cross from such things. I have no intention of maintaining apt-cross after multiarch - it IS going away and dpkg-cross will migrate into dpkg (what is left of dpkg-cross after multiarch). > /etc/apt-cross/rename.list: Change the path name, please. > List of patterns that decide what packages are libraries and what are > binaries. Also handles packages available natively under lib32* or > lib64* name (or other) where the native one will be prefered. E.g. on > amd64 libc6-i386 is to be used instead of libc6-i386-cross. This is > the only external and global information used. Why can this not be calculated from the Multi-Arch fields? > The implementation of all this is a bit tricky and scary at first but > keep an open mind. The main idea is to change as little as possible > while getting all the features needed. So is this still part of the transition or are you expecting any of this to be necessary AFTER multiarch? > Dpkg: > > The wrapper around dpkg just adds /usr/lib/apt-cross/ to PATH so > /usr/lib/apt-cross/dpkg-deb is used to unpack debs. Please drop that mention of apt-cross - it is misleading. You cannot unpack into /usr/ anything - it has to /tmp or /var/ > With -e, --control the control.tar.gz is first unpacked and then the > control file is processed. The package name and package relationships > are changed just like for apt. So "dpkg -e libfoo_1.2-3_arm.deb" will > result in a DEBIAN/control file for libfoo-arm-cross that depends on > libbar-arm-cross and so on. The renaming happens like the old > dpkg-cross did with the changes recently mentioned about multiarch > packages. The big change is that this happens when the control.tar.gz > is unpacked by dpkg instead as seperate process between downloading > and installing. If it exists /usr/share/apt-cross/<package>.control is > executed to do extra modifications needed. Why? If this is during the transition, we just use dpkg-cross as now. If it's after the transition, there should be no need for any -cross package. > With --fsys-tarfile first the control.tar.gz file is unpacked and > checked if this is a native package, foreign package and if it is > multiarch or not. Native packages are left unchanged. Multiarch > foreign packages without -cross in the name are also left unchanged. Why is "foreign" insufficient? Why are we expecting to have -cross versions at all? > Multiarch foreign packages with -cross in the name are changed to > dummy packages just containing a changelog. That's already being done in the changes already described on this list about the Multiarch transition. However, *all* multiarch packages are handled that way. > Non multiarch foreign > packages are unpacked to a temporary directory and then files are > moved around. Include files to /usr/include/arm-linux-gnu, libraries > to /usr/lib/arm-linux-gnu, binaries thrown away and so on the same way > dpkg-cross moves files around now (except with multiarch dirs now). > If it exists /usr/share/apt-cross/<package>.data is executed to do > extra modifications needed. I don't see how this fits with the changes I've already got pending. > Not all packages can be transformed fully automatically. Some need > some extra handholding. For those cases the <package>.control and > <package>.data hooks are available to do whatever custom > transformation they need. For example libgtk2.0-0 needs this for i386 > debs on amd64 (old hook from ia32-libs): > > # Fix path for plugins > sed -i 's,/usr/lib/,/usr/lib32/,' > usr/lib32/gtk-2.0/2.10.0/immodule-files.d/libgtk2.0-0.immodules sed > -i 's,/usr/lib/,/usr/lib32/,' > usr/lib32/gtk-2.0/2.10.0/loader-files.d/libgtk2.0-0.loaders For gtk to be multiarch-compliant, that needs to be done in the package. > So that's it. Let the flame fest begin. I think you're putting far too much weight onto apt-cross - it really, really cannot take it and fixing it is simply not reasonable. Forget apt-cross, for multiarch purposes, it simply isn't usable, it doesn't exist. dpkg-cross will merely be a set of config files in dpkg and -cross packages should not exist, apart from those few empty dummy ones from the current pending changes in dpkg-cross and apt-cross. Please reduce the expected workload of dpkg-cross and apt-cross and think of any -cross package as automatically inferior and "deprecated". -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpS68R9uL2ov.pgp
Description: PGP signature