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

Re: armhf TODO (was Re: Fosdem 2011: Debian on ARM)

On Monday 07 February 2011 13:15:15 Luke Kenneth Casson Leighton wrote:
> On Mon, Feb 7, 2011 at 10:43 AM, Konstantinos Margaritis
> <markos@genesi-usa.com> wrote:
> > On Sunday 06 February 2011 14:55:19 Hector Oron wrote:
> >> Hello,
> >> 
> >>   Wookey and I have prepared a last minute talk to explain later
> >> status on Debian ARM, a bit of history and future plans.
> >> 
> >>   If you have not been able to attend to it, you might find the talk
> >> slides at: http://people.debian.org/~zumbi/talks/fosdem2011-arm/
> >> 
> >> Best Regards,
> > 
> > Nice talk guys!
> > Ok, regarding the TODO phase, I have some things to add:
>  also, just a gentle reminder, konstantinos: before the information is
> lost and/or diffs become too big, a complete record / snapshot of
> every package and thus much more importantly every package *change*
> that has been made, in order to create the initial bootstrapping, is
> absolutely essential to make available, publicly.

Heh, I read that mail before but I forgot to reply. Basically, there is no 
such record. Porting involved lots and lots of hacks, porting debian to a new 
architecture is certainly not straightforward or "friendly" process, it 
requires too many failed attempts -build a package with those flags, then it 
fails, then you rebuild it again, until it succeeds, then you realize that it 
wasn't built with a specific build-dependency, so the package is missing 
functionality, but that build-dep is not available for the port yet, so here 
goes again...

Keeping notes in the process would be like a mathematician keeping track of 
his theorem proof attempts -ie, not very often done :)

OTOH, it's quite easy to see the diffs for most failed-on-armhf packages if 
you check the TODO wiki page, and/or the usertagged 'armhf' bugs on the Debian 

>  making what you've achieved so far publicly available is absolutely
> essential in order to a) save time for future people who may wish to
> create ports b) save time in case a complete total recompile/rebuild
> due to some subtle but unforseen and unavoidable change is required.

I know and I agree with you, but in short it wouldn't help much, even if I 
kept notes. The main problem, er, no, the ONLY serious problem in porting to a 
new architecture is cyclic build-dependencies. If that is not solved, either 
by an extra control field, or more packages, or in the policy and with clever 
tools that detect circular dependencies spanning lots of packages -ie not just 
self-dependencies- then it's the problem will not be solved.



Reply to: