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

Re: Crush 2.0 abandoned

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?

>> 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.

		-- Héctor Orón

Reply to: