Re: Policy changes which completely break apt-cross
Hi,
On Thu, Jul 01, 2010 at 09:47:39AM +0200, Goswin von Brederlow wrote:
> If the package is Architecture: all then it won't be renamed for
> apt. That means apt will pull the original package and install it
> natively.
That assumes working multiarch. Currently, header-only libraries like
Boost or ASIO come in arch:all packages, but still need conversion. Some
maintainers have also started splitting out header files into an
arch:all -common-dev package.
> If the package is Architecture: any then there better be some files in
> it worth installing.
We do need to handle the case where there are none, though.
> 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.
> In my case the dependency resolving of -arch-cross packages is
> integrated with the native packages. So the dependency resolution does
> not actualy terminate at the first empty package but continues with the
> native packages then. With is the feature that makes apt-ma-emu work and
> apt-cross fail far too often.
Terminating at the first empty package is my heuristic. The correct way
would be to follow all dependencies, and then remove the ones from the
graph that go through empty packages and provide no benefit (i.e. don't
pull in nonempty packages). The latter rule is needed because every
package eventually depends on libc.
> One big problem with the heuristic approach, both by name/arch and by
> contents, is that you get problems when you have multiple dists
> (stable/testing/unstable/experimental) and the heuristic differs between
> them. E.g. foobar is arch:any in stable but arch:all in testing. So do
> you pull in foobar-armel-cross or not?
The Contents approach is better here: the -dev package has interesting
files either way; if one doesn't, then either our way of identifying
interesting files is wrong, or it is acceptable to drop the dependency.
Simon
Reply to: