If you're using dpkg-cross only with packages from Lenny or Etch, this won't apply. If you're using dpkg-cross only with packages that are not in Debian, this won't apply. To use dpkg-cross during the transition to multiarch (when dpkg-cross itself will go away), you will need to be careful and be strict about how dpkg-cross is used. *This is a one-way process!* If you need to downgrade, use a new chroot! Examples: (Where libfoo is mentioned, libfoo-dev is also included.) libfoo-armel-cross_0.0.1-1_all.deb - Non-multiarch libfoo, the current package, containing real armel files in /usr/$triplet/. libfoo_0.0.2-1_armel.deb - first version of libfoo that is multiarch compliant. libfoo-armel-cross_0.0.2-1_all.deb - the problem package. (Hereafter termed "multiarch-cross" which is an oxymoron and leads to the changes that are being implemented in dpkg-cross.) Once libfoo is multiarch compliant, dpkg-cross must not convert any of the files from the package because there are so many old and crufty versions of libtool around (in reverse dependencies) that we cannot be certain that builds of packages depending on libfoo will get the correct files. To force the builds to find the multiarch location, the old -cross location must be empty. Simply not building the -cross package is not possible as there will be reverse dependencies of the -cross package. (Same reason, we can't change the -cross package name either.) This is where builds will start failing. Therefore, all versions of libfoo-ARCH-cross AFTER libfoo becomes multiarch-compliant, will be empty packages, with the description clearly mangled to indicate that the package can be removed as soon as the installed reverse dependencies are also multiarch compliant. The resulting problem: -------------------------------- When dpkg-cross builds a -cross package, it then needs to know which -cross packages from the dependency list are real ones and which are empty ones. (Not all of these are necessarily installed already.) To generate a list of all packages that are multiarch compliant (and therefore would generate empty -cross packages if handled by dpkg-cross) we need to parse the relevant Packages file and isolate a list of binary package names which have the relevant Multiarch: fields in their control stanzas. The problem, for dpkg-cross, is WHICH Packages file. dpkg-cross, like dpkg, cannot possibly know anything about suites or be expected to cope with complex package replacements (apt does that, dpkg fails if it has to remove lots of packages when just using dpkg -i or -r). Therefore, in order to use dpkg-cross during the upcoming multiarch transition (as opposed to using dpkg-cross with packages already in stable), there will be a requirement to accept some pain. That pain means ensuring that the list of packages that are multiarch-compliant is absolutely and precisely reliable. A helper script is being developed within apt-cross (because apt should know about suites and Packages files) but the list itself can be generated by any method you choose - as long as it is utterly reliable and always updated before new -cross packages are built. The location of this file is, as yet, undecided. It *should* be in /etc/ but apt-cross would then need to run under sudo to update it, which is something we've avoided before. It could go in the apt-cross directory (/home/$user/.apt-cross) which solves the sudo problem but isn't particularly friendly for dpkg-cross (which doesn't know which value to use for $user). Arguably better is a new apt-cross hierarchy below /var/lib/ (where apt-cross should probably have been putting it's data all along but it's too late for that now.) Likely, there will be a default location in /etc/dpkg-cross/multiarch-cross.d/ and then the file in /var/lib/apt-cross can simply contain updates which are appended to the list. (Multiarch compliance being a one-way street.) apt-cross --update would then call a helper script (/usr/share/apt-cross/update-multiarch.pl) to do the work of reading the content in /etc/dpkg-cross/multiarch-cross.d/ (into which local admins can drop files directly or wait for updates to dpkg-cross), read the latest Packages file immediately after download, calculate any additions and put the additions into the /var/lib location. (If the local admin chooses to copy those into the /etc/ file, normal dpkg behaviour can retain those and the helper will purge the /var/lib/ list. Naturally, the list is currently empty. Possibly, the helper could have an option to migrate the .apt-cross data into /etc/, if run with sudo but the /var/lib/ location will be chmod 666. The helper script will *not* complain if the current list contains package names that do not exist in the supplied Packages file, it will simply retain those names (to cope with external and local packages). Listings from all files in the /etc/dpkg-cross/multiarch-cross.d/ and /var/lib/apt-cross/ locations will be concatenated together and a sorted unique list derived by perl during dpkg-cross processing. It will be supported to not have /var/lib/apt-cross/ if you choose to update the lists separately. dpkg-cross multiarch-cross behaviour will be: 1. Absolute and total reliance on the accuracy of the config file(s) created, updated and maintained by a separate process, e.g. update-multiarch.pl from apt-cross (new helper). (If you need two configurations, use one or more chroots.) 2. If the binary package name being handled by dpkg-cross exists in that config file, create a multiarch-cross version - if not, behave precisely as now. 3. multiarch-cross versions have NO files in the package of any kind. 4. multiarch-cross versions have a mangled description indicating a dummy package 5. multiarch-cross versions depend on the multiarch native package, i.e. libfoo-ARCH-cross depends on libfoo at or greater than the version of libfoo that first includes multiarch support. 6. multiarch-cross versions include a new control field: X-Multiarch: delete 7. multiarch-cross versions have exactly the same package name as now, e.g. libfoo-armel-cross, to avoid disturbing reverse dependencies. This config list is simply a list of binary package names, one name per line. No other data is included. Comments (lines beginning with #) will be allowed but the apt-cross helper won't insert comments itself. The listings in the config file(s) doesn't have to be in any particular order, so the helper that I'm writing for inclusion into apt-cross can be entirely optional - as long as the data is reliable. (i.e. if you break it, it's your problem.) apt-cross will gain support to call this helper whenever --update is called but the helper can also be passed any particular Packages file. This means that any one environment (chroot etc.) must be absolutely and irrevocably tied to a single target suite as dpkg-cross cannot tell which suite to use. emprunecross will gain support to check for X-Multiarch: delete and list those packages - alongside a list of packages that are NOT X-Multiarch: delete. When the second list is empty, your environment has completed the multiarch transition and no further -cross packages should be necessary - at that point, emdebuild --build-deps and other processes that calculate the reverse dependencies will need to adapt to not attempting to create any -cross packages. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpep5ju9DUFi.pgp
Description: PGP signature