On Thu, 21 Jan 2010 13:00:37 +0100 Goswin von Brederlow <goswin-v-b@web.de> wrote: > >> > How are you populating the apt cache? Trying to fool apt into > >> > thinking that -cross packages exist in a repository is going to > >> > break when dependency chains get long. > >> > > If the package name has changed in that process, the new package name > > is unknown to apt. > > I think now we are getting somewhere. That is exactly where my code > differs. I was coming to that realisation too. > The Apt::Update::Post hook changes the binary-arm/Packages > file apt downloaded so that it does list the -cross packages with the > altered package relationship but keeps the Filename pointed to the > native arm deb. That way apt does know about the -cross packages, can > resolve the dependency chains and downloads the native arm package and > renames it to -cross locally (just renames the file). It then calls > Dir::Bin::dpkg (which points to the dpkg wrapper) to install > libfoo-arm-cross_1.2-3_all.deb (or _arm.deb). The dpkg wrapper handles > the actual conversion from arm to -arm-cross. Quite a different process from dpkg-cross/apt-cross. You're doing the renaming *ahead* of the conversion instead of after it because that allows you to insert the renamed listing into the apt cache. Presumably your new apt-hookma is in /usr/sbin/ rather than /usr/bin like apt-cross? > >> A -cross package can depend on a arch:all package, a binary package > >> (arch: native), a multiarch library or a -cross package. And only a > >> -cross package can depend on a -cross package. > > > > Having -armel-cross depending on a non-multiarch libfoo just doesn't > > work with apt-cross. > > We do need that for the multiarch dummy debs. > > libfoo-arm-cross_1.2-3_arm.deb depends on libfoo (= 1.2-3) when libfoo > is Multi-Arch: same. Yes, we do - and the latest changes in old apt-cross will allow that. Where things break is if old apt-cross (or dpkg-cross) are asked to handle situations where libfoo-arm-cross depends on libfoo BEFORE libfoo has been multiarched *in the relevant suite*. The reason for those problems is (almost) entirely down to how apt-cross has to convert the package BEFORE it is installed and is not able to insert that data into the main system apt cache. apt-cross doesn't have access because it only looks for sudo to converting the package with dpkg-cross and even then only if going on to install. > >> It is hard to find a good name. apt-cross is not enough but > >> apt-multiarch promises too much. It isn't real multiarch as it still > >> uses -cross packages. > > > > ... albeit only in such a way as to ensure the removal of -cross > > packages. > > > >> I'm open to suggestions for something inbetween. > > > > It could only be apt-cross if there was a way to migrate from apt-cross > > to your script - I can't see that working. > > Where exactly do you see a problem migrating? > > Apt-cross (or just dpkg-cross) user you have some -cross packages > installed and listed in /var/lib/dpkg/status. Now you throw away > everything from apt-cross and install apt-hookma (or whatever the name > will be). Add "arm" to Apt::Architectures, apt-get update, apt-get > dist-upgrade. OK, I think here we need to be able to test just such a migration. The biggest test, for me, will be #502433 because that involves all the steps that apt-cross needed to perform for it's reverse dependencies. > I don't provide a option identical apt-cross binary (or any apt-cross > binary) so it isn't a drop in replacement. So scripts that call > apt-cross will have to be changed. But for users it should be just a > matter of forgetting about apt-cross and use only apt-get. Which means that the new script should have a different name, in a package other than apt-cross or dpkg-cross. Then, once emdebian-tools has migrated, emdebian-tools can Conflict: with apt-cross even if it retains libcache-apt-perl. The new package can conflict with apt-cross but it can't Provide: it - although during testing we don't want a Conflict: either. Scripts need the following functionality (not necessarily using this syntax or these options): 1. $ sudo apt-foo -a armel build-deps PACKAGE 2. $ apt-cache search [a given once we can use the main system apt] 3. $ sudo apt-get -a armel install PACKAGE 3. $ apt-get -o Apt::DownloadOnly=true install PACKAGE 4. ONLY require sudo for installation or update processes, just like existing apt - all cache queries must be userland. It would be good if [3] could be done without sudo (as it is now with apt-cross) but it's not as big an issue as having apt-cache accessible without sudo. However, porting the scripts to use any version of a replacement for those commands will involve large amounts of work - and testing. The work will be considerably eased when we have a way of installing the toolchains without needing to calculate the current version of gcc and libc6 etc., i.e. once toolchains are available within Debian (zumbi). :-) What I'd like - for now - is to know if your scripts can do a full build-deps install working in a clean chroot (with only a cross-toolchain added to a normal debootstrap+build-essential) at least as high as the complete build-dependencies for packages which build-depend on libgpewidget-dev - say gpe-calendar or gpe-bluetooth (to pick a hard one for the dependency list but one that will at least build with just dpkg-buildpackage -a without needing emdebuild itself). How do your scripts handle build-dependency lists where some (like automake) need to be native and some (libfoo-dev) need to be cross but Build-Depends contains all in one line? (apt-cross/emdebian-tools use a debian/xcontrol file in each package with Build-Depends and Build-Depends-Tools.) That's the biggest issue for me - I might have the wrong impression here (not for the first time) but your work appears to concentrate on runtime requirements and preparing a buildtime environment is a subtly different problem. It *might* be possible to convert the libcache-apt-perl module to get data from the main system apt cache - at least as an interim measure. (It would have to abandon all attempts to update the main apt cache with apt-get update so that scripts can continue to operate without sudo but I think I can add a new function that disables the relevant components.) I did anticipate that libcache-apt-perl might survive longer than apt-cross itself - turns out that work on Grip has provided other ways to read data from Packages files which are far, far, easier to handle in perl than the actual apt cache that apt builds from the same Packages files. i.e. The problems underlying libcache-apt-perl are simply down to the fact that we are trying to understand what C++ does to a collection of Packages files using perl bindings on that C++ when it may turn out to be easier to read the Packages files into perl directly and skip the pkgcache.bin files and the whole C++ mess entirely. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp8DBq0KYkL9.pgp
Description: PGP signature