[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: next generation apt/dpkg-cross

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

$ 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

> /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

> 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

Attachment: pgpS68R9uL2ov.pgp
Description: PGP signature

Reply to: