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

Re: Policy changes which completely break apt-cross

Simon Richter <sjr@debian.org> writes:

> Hi,
> On Wed, Jun 30, 2010 at 04:11:15PM +0200, Goswin von Brederlow wrote:
>> FYI: This is a non-issue for apt-ma-emu. The libfoo-dev-arch-cross
>> package will just depend on libfoo-dev-common or
>> libfoo-whatever-arch-cross and pull them in too.
> This means that we pull all the packages, then notice that there aren't
> any files worth installing, and create an empty package to fulfill the
> dependency.

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

If the package is Architecture: any then there better be some files in
it worth installing.

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.

> Obviously, this works, but is wasteful. My suggestion was to look ahead
> using the Contents file, and terminate dependency resolution on the
> first empty package. The latter is not entirely correct, but good
> enough.
>    Simon

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.

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? Pulling it in and coping with the
fact it might be emtpy would be the save option. That is one thing I
sort of ignored for now.


Reply to: