On Wed, Aug 12, 2009 at 01:52:13PM +0200, Hector Oron wrote:
Hi Jonas, En/na Jonas Smedegaard ha escrit:On Wed, Aug 12, 2009 at 12:58:53PM +0200, Hector Oron wrote:Could someone please point me to documentation/diff betwen 2.0 and 3.0?[PACKAGES]For Crush 2.0 (before multiarch), *it is not worth it to work on it*, with current approach, it is too much time consuming (Neil has already pointed out some of the drawbacks). But it is better to work for Crush 3.0.Crush 2.0 is released with Debian 6.0 Squeeze, so Crush 3.0 will be released with Squeeze+1, by then we'll have multiarch, and {dpkg,apt}-cross will not be longer maintained and those will be merged under proper apt and dpkg which it is our long term goal (Crush 3.0 or 4.0). Package source format (we wish) will allow to have foreign dependencies (build-cross-depends or bootstrap dependencies fields). Multiarch solves many things, but it will not be ready for our needs on Squeeze, but it could be ready for Squeeze+1. What I (also Neil) meant it is better to work towards that approach than fix apt-cross perl bindings, dpkg-cross and patch all the packages to be able to cross build properly for Crush2.0 which will be deprecated after multiarch is ready. Did I make sense?
Are Crush releases directly tied to Debian releases, with whatever features included that happen to be implemented at time of Debian release?
...and that the detailed features you mention above are just some that you _believe_ are likely to get implemented in time for those next Debian releases?
Or is it that Crush releases are _loosely_ tied to Debian releases - i.e. released no earlier than Debian releases, but possibly much later, depending on how soon wanted features are implemented?
But, Neil, what do you think on having a debian/rules which points to debian/rules.d/$native_rules if DEB_BUILD_ARCH == DEB_HOST_ARCH and debian/rules.d/$cross_rules if DEB_BUILD_ARCH != DEB_HOST_ARCH? With this and xcontrol, we might be able to make it possible and easy for crush 2.0, but as you said it might not worth the time if everything changes.This sounds odd: You want to rewrite packaging scripts for *all* packages that needs cross-compiling? Or when would above make sense?Current workflow for crush, download a package from debian, patch, build, fix and rebuild. Now, patches does not apply. So, I was just suggesting, in case somebody wants to work on crush 2.0, to have separated files for cross instead patching Debian one, so i assume that patches can be useful in longer term in an automated build system.
This still sounds to me like you want to completely ignore Debian packaging and instead use a completely separate packaging directory.
Yes, if completely ignoring ./debian then patches won't fail. But that approach will also not reuse any of the Debian packaging efforts. I got to be misunderstanding somethong here - I *know* that you are more clever than that ;-)
- Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: Digital signature