[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Crush 2.0 abandoned

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:
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.
Could someone please point me to documentation/diff betwen 2.0 and 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

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

Reply to: