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

Re: next generation apt/dpkg-cross

Neil Williams <codehelp@debian.org> writes:

> On Wed, 20 Jan 2010 18:49:22 +0100
> Goswin von Brederlow <goswin-v-b@web.de> wrote:
> (Please don't CC: me, I read the list.)
>> >> I don't see why. Since I'm populating the apt database with the
>> >> native, the foreign multiarch and the -cross packages the update
>> >> process can use either one or any combination of them. So when a
>> >> new version of a package comes out the -cross package will be
>> >> upgraded just like a native or foreign multiarch package.
>> >
>> > 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.
>> But they do exist.
> Only in /var/lib/dpkg/status and that isn't enough for apt - at least
> it isn't when dealing with long dependency chains with apt-cross.
>> Apt-get will download them and tell dpkg to install
>> them.
> 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. 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.

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

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

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.

> apt-hookma ?
> There are already too many packages starting with 'apt-*' - maybe some
> other name is going to be better.
> I also think that your script would suffer adversely from being named
> 'apt-cross*' because of the problems within apt-cross.
> multiarch-hooks ?
> ma-apt ?
> maahook ?
> It's a transient package, it doesn't need to be a particularly
> "attention-grabbing" name, doesn't even have to be that intuitive.
> I just think it should downplay the -cross elements which it tries to
> replace.
> multiapt-tools ?


Reply to: