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
BTS.
> 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.
Regards
Konstantinos
Reply to: