Bug#632221: Add cross-dependency satisfaction to apt
+++ David Kalnischkies [2011-07-02 15:51 +0200]:
[sorry, missed your response to this - would have replied sooner - too
much mail!]
> On Thu, Jun 30, 2011 at 17:42, Wookey <wookey@wookware.org> wrote:
> > So the implementation work needed is
> > 1) to parse build-dep modifiers separated by a ':' (as for the existing
> > :any in Depends). These will ultimately include all architecture
> > names, but currently we just allow :any and :native.
>
> You mean build-deps like pkga:i386, pkgb:armel, right?
correct
> You hopefully don't ask for pkga:!hurd-any …
hopefully not.
> Terminology in the Spec mentions ":same" and ":both". What's that?
> And more important: Do you need it or is it a left over.
:same is a left-over from previous iterations. Ignore.
:both is an issue that needs discusison.
A package might need to depend on both the build-arch and host-arch
versions of a package (e.g. pkga:amd64 and pkga:armel). This could
either be represented by
pkga:both, or
pkga, pkga:native
I don't know if there is a problem listing a build-dep twice and it
would be better to have a qualifier? I think listing it twice is
better/clearer, but you're the expert here.
> > Here is a page which provides some useful test cases:
> > https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/CrossDependencyList
>
> Could the Packages-stanzas for these packages be added
> to the page, so that a reader don't have to guess that lib's are all
> M-A:same - and that all other packages are not multi-arched as M-A:allowed
> would let them end up in the other column…
> (the dependency-cycle between table and examples is just to hard to break)
The package stanzas for the depended-on packages? or the depending
packages? It's the depended-on ones that contain the relevant M-A:
entries. I'm not sure how to add those - I could annotaed each
dependency with the current M-A status but that's going to be a big
pain if/when they change. We could have a second table showing simply
packagname, M-A status? I guess that would work.
> Further more, could the usage of "Native/Cross deps" be replaced
> with "DEB_{BUILD,HOST}_ARCH" or something similar.
> For someone like me who has never even tried (successfully) to cross-
> compile something the mixture of terminologies is a bit confusing.
OK. Will do (Done in fact). The prob is that DEB_{BUILD,HOST}_ARCH confuses everyone
who isn't already steeped in this stuff :-)
> And as alsa-lib includes a whole lot of architecture limited build-deps:
> Which host/build arch is assumed in these examples?
good point. In practice BUILD=amd64, HOST=armel, so I've clarified
that.
> And these limits apply to host arch, right?
you mean the arch constraints on build-deps? Very good question. I'm
really not sure in general but in that alsa-libs example, yes it must
be for the host arch. I'm not certain that that is always the case
without thinking about it some more.
> But to answer at least one question after raising so many new ones:
> I wouldn't go as far as saying that it is easy as it includes quiet a bit
> of shuffling around architectures and i remember that the build-dep
> code isn't the nicest one on earth, but yes could be done and as i
> did most of the other MultiArch stuff i guess that is a todo for me…
That was the impression mvogt gave :-)
> So whats the status/opinion of dpkg and co. on this?
> I recently learned with MultiArch the hard way that implementing a
> spec is as easy as walking on water - so is it frozen already?
Is this multiarch cross spec frozen? almost/we think so. Although we
have just realised there is no real need to have both :any and :native
as they are so similar. Just implementing :native would suffice.
Changes will only happen now if we realise during implementation that
there is something important we have forgotten to deal with.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: