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