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

Re: Policy changes which completely break apt-cross



On Thu, 01 Jul 2010 11:04:57 +0200
Goswin von Brederlow <goswin-v-b@web.de> wrote:

Please don't CC: me, I'm on the list.

> Do i remember correctly that dpkg-cross by default skips the package if
> the result would be empty? But yes, empty (except for /usr/share/doc/*)
> packages have to be handled corectly.

No, you do not remember correctly. If apt-cross gets the calculation
wrong and downloads debconf, dpkg-cross will create an empty
debconf-armel-cross package.

This all happens BEFORE dpkg-cross gets involved - it has to be decided
by the tool doing the downloading.

> >> But yes, worst case we end up pulling a -arch-cross package in that is
> >> just empty. Apt-cross could actually do that too. But that is the tricky
> >> part since it involves some form of guessing. I use name and
> >> architecture from the Packages file. You suggest using the Contents
> >> file. Using the Contents file might be better but only if you have one
> >> and it is current.
> >
> > Right -- so one could use "download and attempt conversion" as a
> > fallback method.

This is just going round in circles and doesn't solve the other
problems, just hides this one problem inside yet another hack.

> 
> Just thought about something. The contents file tells you if the package
> contains usefull files.

No, that is not a sufficient measure of "useful" for dpkg-cross.
dpkg-cross needs to see the files in order to say if there are any
useful ones.

> It does not tell you wether the dependency chain
> ends there or crosses into the native chain. Even if bar is an empty
> package the architecture decides how the dependencies must be followed:

... and this is the ongoing problem which has not been resolved.
 
> This does asume that Arch: all package do not need to be converted ever
> like I said above.

The whole point of this Policy change is that Arch:all packages WILL
need to be converted, we just won't know which we can allow and which
we cannot.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgpGfcsI5enUu.pgp
Description: PGP signature


Reply to: