Re: Policy changes which completely break apt-cross
Simon Richter <sjr@debian.org> writes:
> 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.
I don't think so. What would you change in the conversion? With
sysroot=/ the include files don't need to be moved to
/usr/triplet/include, the /usr/include is just fine.
>> 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.
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.
>> 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
Just thought about something. The contents file tells you if the package
contains usefull files. 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:
Package: foo -> foo-armel-cross
Architecture: armel
Depends: bar -> bar-armel-cross
Package: bar -> bar-armel-cross
Architecture: armel
Depends: baz -> baz-armel-cross
Package: baz -> baz-armel-cross
Architecture: armel
Install foo-armel-cross, bar-armel-cross and baz-armel-cross. You do
have to install an empty bar-armel-cross so that it depends on
baz-armel-cross. If you skip the empty package then the dependency chain
will be broken and autoremove would suggest removing baz-armel-cross.
Package: foo -> foo-armel-cross
Architecture: armel
Depends: bar -> bar
Package: bar
Architecture: all
Depends: baz
Install foo-armel-cross, bar and baz.
This does asume that Arch: all package do not need to be converted ever
like I said above.
MfG
Goswin
Reply to: