[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 01:52:13PM +0200, Hector Oron wrote:
>> En/na Jonas Smedegaard ha escrit:
>>> On Wed, Aug 12, 2009 at 12:58:53PM +0200, Hector Oron wrote:
>>>> [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.
>>> 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?

Yes, Emdebian (Crush & Grip) releases are directly tied to 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?

Yes, as Neil said, Crush might be much easier within multiarch context.
There is already an effort to implement multiarch to replace ia32-libs,
but we need to think and write a paper about our needs, cross
compilation bits for Crush >3.0, because this surely will not be ready
for Crush2.0.

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

Correct me if I am wrong, but we tight to Debian because we feel that is
the way to go, of course we can release later, but our tools that we
ship in Debian need to be done by Debian freeze.

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

That would make it posible to have Crush2.0.
For Crush3.0 or later (after multiarch) we want the same packaging as in
Debian, that is the main reason of dropping Crush2.0 development.

> 
> 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 ;-)
> 

I am only clever to pick up the place to eat ;-)
What I was proposing here is a half way hack before multiarch to fill in
the GAP of Crush2.0, but i still believe it is worthless to work on it.

Cheers,
		-- Héctor Orón

P.S.- When we talk Crush2.0 it means it is released along Debian6.0,
Crush3.0 with Debian7.0 and so on.


Reply to: