Re: Policy changes which completely break apt-cross
Neil Williams <codehelp@debian.org> writes:
> On Thu, 01 Jul 2010 15:36:03 +0200
> Goswin von Brederlow <goswin-v-b@web.de> wrote:
>
>> Neil Williams <codehelp@debian.org> writes:
>>
>> > 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.
>
>> % dpkg-cross -b /var/cache/apt/archives/debconf_1.5.32_all.deb
>
> Wrong. This has nothing to do with dpkg-cross at this stage, this is
> all about apt-cross which cannot know if dpkg-cross would skip the
> package if it was specified in a single command.
>
> You cannot allow such packages to be skipped UNLESS you also handle the
> reverse dependencies of the generated -cross package to either not
> depend on the -common-cross package because it wasn't cross'd or to
> depend on the native -common package for the same reason. apt-cross
> cannot make that decision without knowing if dpkg-cross considers the
> package does not contain useful files and therefore apt-cross has had
> to guess (heuristically) that Arch:all packages are generally unsafe to
> allow as foo-common-armel-cross because such packages may be perl and
> then depend on other Arch:all packages which cannot be safely cross'd.
I never mentioned skipping them, that was you. I believe in quite the
reverse. I want empty packages to preserve the dependency chain as is
rather than rewriting the chain to skip something. And then you said
"dpkg-cross will create an empty debconf-armel-cross package". Which is
not true by default. That is all I say. For apt-cross to work with such
empty packages the -A option musst be passed to dpkg-cross.
> Do not think you can test this by just calling dpkg-cross, this MUST be
> processed through the entire dependency chain using apt-cross or
> something else which can try and work out which packages need to be
> cross'd in order to install a -cross version of the top level package.
>
> This problem is a middle-package issue. Things are trivial if you only
> consider the dpkg-cross single-command but that completely misses the
> point. The issue is when package A is a dependency of package B and
> your build needs the cross version of package B. Package A now changes
> to this new Policy and puts various files that were in libA-dev into
> A-common which is Arch:all. When trying to prepare the
> cross-dependencies of package B, just how is the dependency solver
> meant to find A-common when foo-common is known to cause uninstallable
> situations if it is allowed to appear anywhere in the dependency chain.
It can't. That is the design flaw in apt-cross.
>> dpkg-cross: package debconf doesn't provide any useful files. Skipping.
>
> Wrong - only consider if a package depends on something which depends
> on something else which depends on something else which depends on
> debconf. Without the indirection, you cannot test this problem.
>
>> It does. You need to specify
>>
>> -A|--convert-anyway: convert package even if it does not provide any
>> development files
>
> and apt-cross does specify this. That's the point, dpkg-cross is too
> late in the process, this has to be resolved at the dependency
> calculation stage which is apt-cross.
>
>> % dpkg -c debconf-i386-cross_1.5.32_all.deb
>> drwxr-xr-x root/root 0 2010-07-01 15:25 ./
>> drwxr-xr-x root/root 0 2010-07-01 15:25 ./usr/
>> drwxr-xr-x root/root 0 2010-07-01 15:25 ./usr/share/
>> drwxr-xr-x root/root 0 2010-07-01 15:25 ./usr/share/doc/
>> drwxr-xr-x root/root 0 2010-07-01 15:25 ./usr/share/doc/debconf-i386-cross/
>> -rw-r--r-- root/root 260 2010-07-01 15:25 ./usr/share/doc/debconf-i386-cross/README
>>
>> .oO(Where did changelog and copyright go?)
>
> -cross packages don't have them. Never have.
Isn't that a legal problem when you build a repository out of cross
converted packages?
>> > 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.
>>
>> You haven't yet said why/how the package must be converted.
>
> Because files that were in libfoo-dev and which are architecture
> neutral will not necessarily be in libfoo-dev anymore but could be in
> foo-common which, being Arch:all, apt-cross will studiously ignore -
> this then causes the build to fail because files needed by the build
> are not provided by libfoo-dev-armel-cross, only by foo-common which
> has not been crossed because apt-cross cannot take the risk of allowing
> an Arch:all package to appear in the dependency calculation.
Which is a "bug" in apt-cross. More a major design flaw. The fix is to
get the native Arch:all package pulled in.
Apt-ma-emu have the same problem since the native and cross packages are
handled all by apt in a single go, not by seperate apt invocations.
Dependencies between cross and native packages work perflectly. The only
way for apt-cross to survive is to adapt that mechanism.
Obviously if foo-common is not installed then files will be missing and
the only sane solution is for libfoo-dev-armel-cross to depend on it to
ensure those files are there. So lets assume people have switched over
to apt-ma-emu or apt-cross has adapted the same method and we can depend
on foo-common.
Is there anything known to break from using the files from such a
foo-common package then?
>> What files need to be moved around or altered and why? I can hardly
>> convince you that a conversion is not needed if you don't say what files
>> you think need conversion.
>
> The same files as have always been converted but the files move between
> packages due to this change in Policy.
Please be specific. What files could maintainer move to foo-common that
need to be converted? What breaks by using the native foo-common one
instead of converting?
>> I believe that any file (like *.pc files) that need altering are not
>> actually architecture independent and will differ across architectures
>> with multiarch even if they are identical now. As such I would file a
>> bug for the file to be in the libfoo-dev instead of libfoo-dev-common.
>
> dpkg-cross doesn't convert every file, some (like headers) it doesn't
> need to convert but does need to retain.
And anything it doesn't convert but only retains can happily move to
foo-common. In my opinion that is every file that could move to
foo-common with the exception of the .pc file and .so link. Both I would
argue would be wrong to move to foo-common in the first place.
What I'm looking for is a list of files to give maintainers with the
expressed request NOT to move them to foo-common because that would
break cross-compiling. Something to add as footnote to the new policy.
MfG
Goswin
Reply to: