On Thu, Dec 30, 2010 at 4:52 PM, Martin Guy <[email protected]> wrote: > On Sun, Dec 19, 2010 at 9:30 PM, Wookey <[email protected]> wrote: >> Does the >> popularity-contest info record any CPU details? It would be helpful >> for having some idea of the mix currently in use. > > It doesn't. I suggested this to its maintainer a few months ago, and > they agreed that it would be useful. > > On Sun, Dec 19, 2010 at 10:04 PM, Luke Kenneth Casson Leighton > <[email protected]> wrote: >> * i remember neil said he spent months - almost a year - on the armel port > > "Neil"? I spent 2006 working to bootstrap the armel port, of which the > first 6 months were getting a working EABI cross-compiler (partly > because the emdebian crowd, who seemed to know more about it, urged me > to; in reality you have to build Debian packages natively) and the > last 6 months were spent doing exactly the circular dependency > workarounding that has been described here.
jeezus. what a total waste. sorry, not of your work, but a total waste that this wasn't automated back then, so that konstantinous didn't have to completely re-duplicate it, from scratch. > I got to 91 of the 114 > required packages and these were published by Wookey in November. > Lennert Buytenhek then completed it in two months. Who's Neil? sorry, martin - faulty memory! >> * each and every time someone does a new port, all the knowledge and >> expertise is re-learned, re-discovered... and then lost. > > I asked the same kind of question back then. The answer is that you > have to get to a point where you can natively build the 114 packages > that you need to be able to natively build packages (both those and > others) and the most convenient mechanism to do that varies according > to the available resources, for example other OS's using the same ABI > that can be Debianized sufficiently to fool package builders into > thinking they are running on Debian. This part is different for each > port. > However, I agree that some kind of guide would be useful to future porters i was thinking more in terms of a totally automated, completely scripted "guide". (then by utilising something like the bitbake override mechanism, any exceptions and differences between the architectures can be done very very simply, through the bitbake combination of python + script-auto-generation). you have to bear in mind that "future porting" *used* to be very uncommon an occurrence (as if doing it 14 times is "uncommon") but with the massive explosion in compiler options for ARM processors alone, the process of "porting" now becomes a massive headache. 114 packages, all done by hand, and the effort was totally thrown away. i'm deeply impressed that you did it, and just as equally unimpressed that the work wasn't recorded in a scriptable, reproduceable manner. [criticise and "blame" me for saying that if you wish - it won't change anything] l. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
