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

Re: next generation apt/dpkg-cross



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: pgph8L58KezUi.pgp
Description: PGP signature


Reply to: