On Sun, Nov 7, 2010 at 7:05 PM, Hector Oron <[email protected]> wrote: > Hello, > > 2010/11/7 Luke Kenneth Casson Leighton <[email protected]>: > >> i haven't looked around, but has anyone suggested adding a >> base64-encoded extension to the .deb name, containing a bit-field of >> "capabilities"? the problem with splatting the capabilities into the >> .deb itself is that you then end up with dozens of combinations of >> capabilities, all with the exact same .deb filename. by encoding the >> capabilities in the actual filename, you can still pick a particular >> package by its version number etc. etc. _but_ you can identify whether >> it will work on a particular CPU by decoding its capabilities bits. >> >> 0x1 -> v5, 0x2 -> v6 .... 0x10 -> NEON > > Yes, it is not bad idea at all. There are suggestions on encoding a > flavour field on the Debian package name,
that is allmost the same thing, except you... *thinks* you'd now need to add a "Provides:" with the original name. > other suggestions of > encoding the field after debian version, yes - that's where i had it - in my mind at least :) > other suggestions of handling > multiple repositories with optimized libraries (maybe components). yeah - but ... mmm... >>> * Cross compilation environment (cross toolchains and target packages) - >>> bare metal support > > I want to be able to (cross-)compile my firmware for Cortex M3 or > MSP430. (bare-metal) > >> the level of expertise / machine-specific information is so vast that >> i strongly advise against "beginning from scratch". whilst wookey (or >> neil?) pointed out a few months back that it took several months - >> almost a year - to do the armel port, most of which was done by hand, >> and someone else pointed out recently that they managed in a couple of >> weeks to recompile automatically several hundred packages for Cortex >> A8, gaining a 40% performance jump by doing so, this is still an >> insanely ridiculous situation... when you compare it to openembedded. > > Debian (binary based) != OpenEmbedded (source based) that's the traditional view. actually, i'd say that debian is a hybrid binary+source based. and emdebian dpkg-cross-compilation is _definitely_ source-based. so it's not quiiite as clear-cut as it looks. remember that just because _you_ install binary packages doesn't mean that the packages come out of thin air. (and yes, btw, i'm discovering that openembedded supports the same sort of concept of "-dev" packages) so you're missing the point by saying debian = binary-based, openembedded = source-based: i envisage that openembedded would be utilised to _build_ binary-based .deb packages, not "openembedded would force the installation of source-based packages" which it doesn't do anyway. i envisage - quite literally - openembedded calling dpkg-buildpackage, and that's pretty much it, besides setting up the cross-compiler arguments, and taking care of situations where it all falls in a heap :) > Changes in Debian take longer because we need consensus among > community to do things properly and maintainable in the long term. Why > would I want to cross compile a whole distribution and run an extra > emulation layer ... which if you've ever done cross-compiling of 32-bit apps on a 64-bit system you _know_ you have to have, so it's not like there's any choice in the matter... > (introducing more overhead in maintainability) ... which openembedded have already done the work on, thus making the maintainability "burden" equal to zero.... > if I am > able to debootstrap/multistrap it in less than a minute, [ _somebody_ has to create that debootstrap. now, with a dozen different flags, that "somebody" is now completely overwhelmed by the sheer number of pre-compiled debootstraps needed to be made. ] > then cross > compile my application for faster development/test cycle to run on > that system which already has gone through lots of QA proceedings. why exactly. well for a start, i'd want, just like that guy who did a partial rebuild of the entire debian mirror with Cortex A8 optimisations, to do instead of a partial rebuild of the entire debian mirror to do a TOTAL rebuild of the entire debian mirror with Cortex A8 optimisations. for my special super-duper lovely production screamingly-fast ship-it-noww product i don't _want_ a debootstrap in less than a minute, because that debootstrap will have been precompiled with utter shit options for the N out of 600 ARM licencee variants, and i want the absolute fastest, or the absolute most efficient space-saving. remember that you make these choices for people, whether to enable thumb instructions which give a better compression ratio but worse performance, you are _never_ going to have absolutely everyone happy. yes i'd put up with a debootstrap you-selected-it-all-for-me-and-it-runs-like-a-dog compile-time options for the prototype / demo but i'd certainly not put up with it for production. regarding the QA issue: people who use openembedded, usually, know that they're effectively "Doing A Gentoo". they _know_ that they have to go through their own QA process. but, again, this misses the point: the purpose of suggesting that an openembedded recipe be created which utilises dpkg-buildpackage (or cross-dpkg-buildpackage to be more precise) is to save those poor sods who have to create those QA'd debootstrap images one f*** of a lot of time. i sure as s**t wouldn't recommend TO THE AVERAGE PERSON that they go use openembedded-dpkg-buildpackage to create their own super-duper "a la Gentoo" whoppingly-optimised debian distro from scratch, but bless 'em you can bet that that's exactly what will happen once the tool's created... :) >> question: why not recommend portage / gentoo instead of openembedded? > > Certainly this is a topic to be discussed. How do we provide a useful > user land for systems with short size and memory requirements > (Emdebian/Crush)? emdebian / crush is just a different mirror with a different series of packages. i envisage that openembedded-dpkg-cross-buildpackage would simply be set up to have a different set of stuff in sources.list, and that a build would... just... work! > Do we need to have 100 developers to maintain the > thing? i'd say no. if it turns into 100 developers, then you're seriously doing something wrong. > (*bad idea*) Glibc or uClibc based? Trying to avoid > fragmentation, it would be good to trim down already in use EGlibc,... > It is to be discussed if we provide the tools (buildroot, bitbake,...) > to build from $somewhere sources or if we are capable to provide a > binary based image like the ones used by debian-installer using udebs > or maybe something else $someone stills needs to propose/think about > it. the idea is to simply end up with the exact same .udebs and .debs that you'd normally have to cross-compile by hand. if it takes slightly longer in some cases because you have to run configure inside qemu, that's not a big deal. l. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
