+++ 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 <woo...@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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
